8 ms·

I'm worried that this will make the JavaScript trap[1] even more of a problem. The default operation of the web is to allow remote sites to push non-free appli

by rekado 9y ago

I'm worried that this will make the JavaScript trap[1] even more of a problem. The default operation of the web is to allow remote sites to push non-free applications to your browser that it then proceeds to execute. As people have been shifting towards running everything in the browser (just like people like me run everything in Emacs), this effectively results in a revival of ubiquitous proprietary software. I don't think this is desirable. Granted, we already have this problem with plain minified JavaScript, but as we shift more towards treating the web as a platform for which to compile software, this problem is going to become worse. I'd love for the web to be a set of stable application interfaces that in-browser applications can talk to. Give me the sources and I'll use my package manager to build the JavaScript applications I want my browser to execute for particular online services. I want more control over the increasingly complex software that we're expected to just execute blindly upon reception. [1]: https://www.gnu.org/philosophy/javascript-trap.html https://www.gnu.org/philosophy/javascript-trap.html

Vinnl 9y ago
This is hardly inherent to Javascript/WebAssembly. Installed applications are binary code, i.e. closed by default unless you explicitly provide source code. The same holds true for web applications, however, for some reason we don't care about it being open source that much anymore...
- rekado 9y ago
  Admittedly, I'm looking at this situation from within my comfortable bubble of a GNU system in which I only use software for which I have a source-to-binary mapping through GNU Guix. JavaScript applications are the exception in my environment and they threaten to burst that shiny bubble. Aside: I really think that the terms "open" and "closed" are imprecise and confusing, which is why I avoid them. With deterministic builds and free software I have a mapping from source to corresponding binary; so while the binary may not be directly editable (or "closed") it still is free software and I could edit the corresponding source to obtain a new binary. In my opinion the problem really is one of practical software freedom, which has never been achieved in a satisfying way for web applications.
  - Vinnl 9y ago
    I guess I mostly agree. I just think that theoretically it should be able for web applications to be open source just as much as our GNU systems are, and that it's a shame that in practice, this is often not the case.
    - krapp 9y ago
      The javascript part of web applications are pretty fairly open source. Most libraries are OS licensed (probably MIT) and include plain source along with the minified versions that can be verified, forked, modified or redistributed as desired. Any browser allows the source of any page to be viewed or saved locally - and I would bet dollars to donuts that even with minifiers, most javascript running on the web is still plaintext. Browsers allow turning off javascript entirely, or overriding it with custom scripts using plugins like Greasemonkey, which is a lot more freedom than most native apps provide. The only problem from a free software perspective is that not every line of javascript in the universe is explicitly linkable to a GPL license in a static file, as one would find in, say, a C library. But in every other way (I would argue, in every way that really matters) javascript in the browser is either as free or more free than other languages in their respective environments.
      - Vinnl 9y ago
        Don't forget that there's also a large server component that's usually closed source :)
        krapp 9y ago
        The web throws a monkey wrench into a lot of assumptions the free software model seems to make about what software is - obviously you can't download the source of an entire server stack and compile it, much less rewrite and redistribute it, but that would seem to be what would be required for the web to be 'free.' Ok, technically you could but that would be insane. Even if you consider how much FOSS exists on servers, it's impossible to ever be certain what is running the logic of a site unless you can run it locally, which defeats the whole point of the web. But arguments that javascript in particular is hostile to user freedom seem a bit overstated... and even Stallman doesn't suggest the answer is getting rid of it altogether. Although he does seem to believe that only running free javascript somehow makes it safe to run... which isn't true.
pjmlp 9y ago
Proprietary software doesn't need any revival, because it never went away. The irony is that proprietary browser based software happens to run on top of FOSS libraries and languages, which most companies hardly contribute anything back.
- rekado 9y ago
  > Proprietary software doesn't need any revival, because it never went away. True, though we have reached a point where one could be really comfortable without proprietary software. I certainly am. It's just with an increasingly "appified" web that proprietary software makes again inroads on otherwise free systems.
  - mikegerwitz 9y ago
    > True, though we have reached a point where one could be really comfortable without proprietary software. I certainly am. It's just with an increasingly "appified" web that proprietary software makes again inroads on otherwise free systems. Agreed. I extremely comfortable with my fully free system, and the only risk I have each day (which I've mitigated) for running non-free software is the constant barrage that others attempt to force upon me using my web browser---free browsers gladly download and execute non-free software by default. I gave a talk about this and the issues of package management and code signing at LP2016: https://media.libreplanet.org/u/libreplanet/collection/restore-online-freedom/ https://media.libreplanet.org/u/libreplanet/collection/resto...
- kbenson 9y ago
  So, viral GPL FTW? Seriously, there's no shared libraries in compiled monolithic WebAssembly, is there? I think[1] that means included GPL code will require exposure of the source. Maybe if we're lucky some best practice will emerge that the source is often available as a sourcemap so companies don't have to worry about being sued for infringing the GPL. It sure would be nice to finally see an outcome of companies erring on the side of (legal) caution that's better for consumers. 1: Think because everybody seems to like to argue the specifics of this point.
TazeTSchnitzel 9y ago
JS on the web wasn't open to begin with. Just because it was sometimes human-readable doesn't make it free, to put it how Stallman would.
- rekado 9y ago
  This is another case where the "open/closed" image doesn't apply and only contributes confusion. It wasn't free to begin with --- though there are notable cases where that is in fact the case. There are many JS libraries and full web applications that are in fact software libre. It just isn't really any freedom the users can exercise due to the lack of application interfaces. If I were in the mood for an argument, I'd argue that with all the ugly SOAP and Java services users had more potential freedom than today.
austincheney 9y ago
Use a code beautifier. JavaScript code isn't encrypted or compiled to binary. It is just text.
- rekado 9y ago
  > It is just text This misses the point. Looking at a binary through a hex editor is also just text --- and the binary is also "just code", albeit at a level at which only few people are comfortable to work. Obfuscated code (and generated code in general) is clearly not the preferred form, so it hardly even counts as source code. But let's pretend your point were valid: would it remain valid with WebASM?
  - pecg 9y ago
    Also, with the ever increasing level of software complexity many websites rely on, reading such text isn't as simple as it may seem, to give clear example, Google's default page in only one reference javascript file from apis.google.com has ~8000 lines of code, which is deliberately difficult to understand by itself: variables have weird names, lots of anonymous functions, and so on.
  - nathcd 9y ago
    FWIW, I agree with you, but > But let's pretend your point were valid: would it remain valid with WebASM? Yes (pretending GP's point were valid), because WASM has a text format[1], which is how "View Source" on the web is meant to be used for viewing WASM running in your browser. The text version can be derived from any WASM file (i.e. you can do the equivalent of beautifying JS to any arbitrary WASM). [1] http://webassembly.org/docs/text-format/ http://webassembly.org/docs/text-format/
AboutTheWhisles 9y ago
I don't understand this fear of webasm. Anyone can run their javascript through minifiers, or compile C++ to asm.js right now. Webasm doesn't move the needle of obfuscation much at all. The binary format can be turned into the textual ast representation directly. http://ast.run/ http://ast.run/
- v_lisivka 9y ago
  Same holds true for machine code: Anyone can run their C trough minifiers or compile to machine code right now. Machine code donesn't move needle of obfuscation much at all. The binary format can be turned into textual asm representation directly. Currently, difference in performance between asm.js and WebAsm is about 5%. It doesn't looks like performance gain or portability are main reasons to select WebAsm over JS. IMHO (I'm developer myself), main reason is better obfuscation of the code.
  - AboutTheWhisles 9y ago
    > Anyone can run their C trough minifiers I don't know of any programs that are distributed as C to be run directly like javascript. > Machine code donesn't move needle of obfuscation much at all There are two very fundamental mistakes you are making when equating webasm to raw processor instructions. The first is that webasm even its binary format is still organized in a abstract syntax tree, so its instruction are not flat, they are in a hierarchy. The second is that webasm doesn't take care of the input and output. Right now it doesn't even interface with the document object model, so all the IO is still done through javascript.
    - dymk 9y ago
      > I don't know of any programs that are distributed as C to be run directly like javascript. https://github.com/kripken/emscripten https://github.com/kripken/emscripten
      - AboutTheWhisles 9y ago
munificent 9y ago
I think the idea that "access to source code == freedom" is out of date. Imagine someone gave you a thumbdrive with the complete source code for all of Facebook's products, build system, infrastructure, everything that's checked into their repositories. They also gave you legal carte blanche to do as you feel with it. Would you be free of Facebook? Would you be able to do anything useful with at all? No. The problem is that Facebook still has all of the data and that's where the freedom and control live today. The code is just an interface for it. Online multiplayer game developers figured this out decades ago. The primary way to prevent people from cheating is not by preventing them from hacking or cracking the client application code. It's keeping the game state — the data — only on the server.
- mikegerwitz 9y ago
  Yes that's a different problem different than software freedom: https://www.gnu.org/philosophy/who-does-that-server-really-serve.html https://www.gnu.org/philosophy/who-does-that-server-really-s...
- dllthomas 9y ago
  It's not sufficient. It may or may not be necessary. But it is useful.
- Majora320 9y ago
  >Online multiplayer game developers figured this out decades ago. The primary way to prevent people from cheating is not by preventing them from hacking or cracking the client application code. It's keeping the game state — the data — only on the server. At least, good online multiplayer game developers.
- jancsika 9y ago
  > Would you be free of Facebook? Are you kidding? The source code for the full toolset would reveal how they analyze their data, what they find relevant (even merely based on which types of tools exist and which don't), how access is defined for various categories of employees to access that data, differences between what they claim about those capabilities and the actual infrastructure, problems they've had which they've attempted to fix in changes to the code, how they set prices to sell access to advertisers, how their frameworks to respond to lawful requests for user data from government agencies work (hell, even inferences about which government agencies they respond to), whether or not they've made serious attempts to curb the fake news problem, a full understanding of the ways in which they track people who don't have a facebook account across the web, and probably a whole host of other enlightening details about their entire operation. I'm sure there are people who can make quite accurate guesses about how all of that probably works without looking directly at the code. But if the Snowden leaks tell us anything it's that a handful of security specialists being able to deduce something is completely different that a critical mass of programmers being unable to deny that a problem exists. Access to that code would certainly give developers of FLOSS privacy/security software a better idea of how to protect their users' privacy.
borplk 9y ago
I don't particularly disagree but this theme of ehrmagerd-they-took-err-open-software comments under WASM posts is beginning to look like a meme. > Give me the sources and I'll use my package manager to build the JavaScript applications I want my browser to execute for particular online services. The vast majority of people do not understand or want that. It's mostly a nerd fetish (and I count myself in). > Give me the sources and I'll use my package manager to build the JavaScript applications I want my browser to execute for particular online services. This openness is also a double edged sword. People focus on the warm fuzzy side of it and forget the mess that it tends to create for a platform because no one can ever rely on some features being available for everyone. You will need a never ending amount of feature detection, polyfills, polyfills for your polyfills, transpiling, blah blah blah because oh look someone wanted to exercise their freedom to disable textboxes on their browser. And now they are demanding that you make your application gracefully fallback to handle the case where a textbox is not available. IT'S THEIR RIGHT! Eventually someone will show up with a baked sweet potato and demand that your application must work on their potato because they have disabled all features but still want the functionality. You can't realistically cherry pick underlying software pieces like that. Rather than delivering a buggy software that works under a million different combinations of features and settings I will deliver a package of software that run predictably well on one or more predictable platforms. That is "the atom". You either take it all, or not at all. From my experience the average users tend to be perfectly happy and satisfied with that. They are almost always running with default options everywhere anyway. It's the GNU-enthusiast hacker-types (and I count myself in) that tend to throw a tantrum about their custom preferences and philosophical and technical objections.
pasbesoin 9y ago
I'm worried about the intersection with EME and DRM. No more open web. And the crap will become inextricably intertwined with the content of value. Right now, it's "for content." There is going to be enormous commercial pressure to make it "for everything". We should start reconsidering the term "user agent".

by rekado 9y ago

Vinnl 9y ago

This is hardly inherent to Javascript/WebAssembly. Installed applications are binary code, i.e. closed by default unless you explicitly provide source code. The same holds true for web applications, however, for some reason we don't care about it being open source that much anymore...

rekado 9y ago
Admittedly, I'm looking at this situation from within my comfortable bubble of a GNU system in which I only use software for which I have a source-to-binary mapping through GNU Guix. JavaScript applications are the exception in my environment and they threaten to burst that shiny bubble. Aside: I really think that the terms "open" and "closed" are imprecise and confusing, which is why I avoid them. With deterministic builds and free software I have a mapping from source to corresponding binary; so while the binary may not be directly editable (or "closed") it still is free software and I could edit the corresponding source to obtain a new binary. In my opinion the problem really is one of practical software freedom, which has never been achieved in a satisfying way for web applications.
- Vinnl 9y ago
  I guess I mostly agree. I just think that theoretically it should be able for web applications to be open source just as much as our GNU systems are, and that it's a shame that in practice, this is often not the case.
  - krapp 9y ago
    The javascript part of web applications are pretty fairly open source. Most libraries are OS licensed (probably MIT) and include plain source along with the minified versions that can be verified, forked, modified or redistributed as desired. Any browser allows the source of any page to be viewed or saved locally - and I would bet dollars to donuts that even with minifiers, most javascript running on the web is still plaintext. Browsers allow turning off javascript entirely, or overriding it with custom scripts using plugins like Greasemonkey, which is a lot more freedom than most native apps provide. The only problem from a free software perspective is that not every line of javascript in the universe is explicitly linkable to a GPL license in a static file, as one would find in, say, a C library. But in every other way (I would argue, in every way that really matters) javascript in the browser is either as free or more free than other languages in their respective environments.
    - Vinnl 9y ago
      Don't forget that there's also a large server component that's usually closed source :)
      - krapp 9y ago
        The web throws a monkey wrench into a lot of assumptions the free software model seems to make about what software is - obviously you can't download the source of an entire server stack and compile it, much less rewrite and redistribute it, but that would seem to be what would be required for the web to be 'free.' Ok, technically you could but that would be insane. Even if you consider how much FOSS exists on servers, it's impossible to ever be certain what is running the logic of a site unless you can run it locally, which defeats the whole point of the web. But arguments that javascript in particular is hostile to user freedom seem a bit overstated... and even Stallman doesn't suggest the answer is getting rid of it altogether. Although he does seem to believe that only running free javascript somehow makes it safe to run... which isn't true.

pjmlp 9y ago

Proprietary software doesn't need any revival, because it never went away. The irony is that proprietary browser based software happens to run on top of FOSS libraries and languages, which most companies hardly contribute anything back.

rekado 9y ago
> Proprietary software doesn't need any revival, because it never went away. True, though we have reached a point where one could be really comfortable without proprietary software. I certainly am. It's just with an increasingly "appified" web that proprietary software makes again inroads on otherwise free systems.
- mikegerwitz 9y ago
  > True, though we have reached a point where one could be really comfortable without proprietary software. I certainly am. It's just with an increasingly "appified" web that proprietary software makes again inroads on otherwise free systems. Agreed. I extremely comfortable with my fully free system, and the only risk I have each day (which I've mitigated) for running non-free software is the constant barrage that others attempt to force upon me using my web browser---free browsers gladly download and execute non-free software by default. I gave a talk about this and the issues of package management and code signing at LP2016: https://media.libreplanet.org/u/libreplanet/collection/restore-online-freedom/ https://media.libreplanet.org/u/libreplanet/collection/resto...
kbenson 9y ago
So, viral GPL FTW? Seriously, there's no shared libraries in compiled monolithic WebAssembly, is there? I think[1] that means included GPL code will require exposure of the source. Maybe if we're lucky some best practice will emerge that the source is often available as a sourcemap so companies don't have to worry about being sued for infringing the GPL. It sure would be nice to finally see an outcome of companies erring on the side of (legal) caution that's better for consumers. 1: Think because everybody seems to like to argue the specifics of this point.

TazeTSchnitzel 9y ago

JS on the web wasn't open to begin with. Just because it was sometimes human-readable doesn't make it free, to put it how Stallman would.

rekado 9y ago
This is another case where the "open/closed" image doesn't apply and only contributes confusion. It wasn't free to begin with --- though there are notable cases where that is in fact the case. There are many JS libraries and full web applications that are in fact software libre. It just isn't really any freedom the users can exercise due to the lack of application interfaces. If I were in the mood for an argument, I'd argue that with all the ugly SOAP and Java services users had more potential freedom than today.

austincheney 9y ago

Use a code beautifier. JavaScript code isn't encrypted or compiled to binary. It is just text.

rekado 9y ago
> It is just text This misses the point. Looking at a binary through a hex editor is also just text --- and the binary is also "just code", albeit at a level at which only few people are comfortable to work. Obfuscated code (and generated code in general) is clearly not the preferred form, so it hardly even counts as source code. But let's pretend your point were valid: would it remain valid with WebASM?
- pecg 9y ago
  Also, with the ever increasing level of software complexity many websites rely on, reading such text isn't as simple as it may seem, to give clear example, Google's default page in only one reference javascript file from apis.google.com has ~8000 lines of code, which is deliberately difficult to understand by itself: variables have weird names, lots of anonymous functions, and so on.
- nathcd 9y ago
  FWIW, I agree with you, but > But let's pretend your point were valid: would it remain valid with WebASM? Yes (pretending GP's point were valid), because WASM has a text format[1], which is how "View Source" on the web is meant to be used for viewing WASM running in your browser. The text version can be derived from any WASM file (i.e. you can do the equivalent of beautifying JS to any arbitrary WASM). [1] http://webassembly.org/docs/text-format/ http://webassembly.org/docs/text-format/

AboutTheWhisles 9y ago

I don't understand this fear of webasm. Anyone can run their javascript through minifiers, or compile C++ to asm.js right now. Webasm doesn't move the needle of obfuscation much at all. The binary format can be turned into the textual ast representation directly. http://ast.run/ http://ast.run/

v_lisivka 9y ago
Same holds true for machine code: Anyone can run their C trough minifiers or compile to machine code right now. Machine code donesn't move needle of obfuscation much at all. The binary format can be turned into textual asm representation directly. Currently, difference in performance between asm.js and WebAsm is about 5%. It doesn't looks like performance gain or portability are main reasons to select WebAsm over JS. IMHO (I'm developer myself), main reason is better obfuscation of the code.
- AboutTheWhisles 9y ago
  > Anyone can run their C trough minifiers I don't know of any programs that are distributed as C to be run directly like javascript. > Machine code donesn't move needle of obfuscation much at all There are two very fundamental mistakes you are making when equating webasm to raw processor instructions. The first is that webasm even its binary format is still organized in a abstract syntax tree, so its instruction are not flat, they are in a hierarchy. The second is that webasm doesn't take care of the input and output. Right now it doesn't even interface with the document object model, so all the IO is still done through javascript.
  - dymk 9y ago
    > I don't know of any programs that are distributed as C to be run directly like javascript. https://github.com/kripken/emscripten https://github.com/kripken/emscripten
    - AboutTheWhisles 9y ago

munificent 9y ago

I think the idea that "access to source code == freedom" is out of date. Imagine someone gave you a thumbdrive with the complete source code for all of Facebook's products, build system, infrastructure, everything that's checked into their repositories. They also gave you legal carte blanche to do as you feel with it. Would you be free of Facebook? Would you be able to do anything useful with at all? No. The problem is that Facebook still has all of the data and that's where the freedom and control live today. The code is just an interface for it. Online multiplayer game developers figured this out decades ago. The primary way to prevent people from cheating is not by preventing them from hacking or cracking the client application code. It's keeping the game state — the data — only on the server.

mikegerwitz 9y ago
Yes that's a different problem different than software freedom: https://www.gnu.org/philosophy/who-does-that-server-really-serve.html https://www.gnu.org/philosophy/who-does-that-server-really-s...
dllthomas 9y ago
It's not sufficient. It may or may not be necessary. But it is useful.
Majora320 9y ago
>Online multiplayer game developers figured this out decades ago. The primary way to prevent people from cheating is not by preventing them from hacking or cracking the client application code. It's keeping the game state — the data — only on the server. At least, good online multiplayer game developers.
jancsika 9y ago
> Would you be free of Facebook? Are you kidding? The source code for the full toolset would reveal how they analyze their data, what they find relevant (even merely based on which types of tools exist and which don't), how access is defined for various categories of employees to access that data, differences between what they claim about those capabilities and the actual infrastructure, problems they've had which they've attempted to fix in changes to the code, how they set prices to sell access to advertisers, how their frameworks to respond to lawful requests for user data from government agencies work (hell, even inferences about which government agencies they respond to), whether or not they've made serious attempts to curb the fake news problem, a full understanding of the ways in which they track people who don't have a facebook account across the web, and probably a whole host of other enlightening details about their entire operation. I'm sure there are people who can make quite accurate guesses about how all of that probably works without looking directly at the code. But if the Snowden leaks tell us anything it's that a handful of security specialists being able to deduce something is completely different that a critical mass of programmers being unable to deny that a problem exists. Access to that code would certainly give developers of FLOSS privacy/security software a better idea of how to protect their users' privacy.

borplk 9y ago

I don't particularly disagree but this theme of ehrmagerd-they-took-err-open-software comments under WASM posts is beginning to look like a meme. > Give me the sources and I'll use my package manager to build the JavaScript applications I want my browser to execute for particular online services. The vast majority of people do not understand or want that. It's mostly a nerd fetish (and I count myself in). > Give me the sources and I'll use my package manager to build the JavaScript applications I want my browser to execute for particular online services. This openness is also a double edged sword. People focus on the warm fuzzy side of it and forget the mess that it tends to create for a platform because no one can ever rely on some features being available for everyone. You will need a never ending amount of feature detection, polyfills, polyfills for your polyfills, transpiling, blah blah blah because oh look someone wanted to exercise their freedom to disable textboxes on their browser. And now they are demanding that you make your application gracefully fallback to handle the case where a textbox is not available. IT'S THEIR RIGHT! Eventually someone will show up with a baked sweet potato and demand that your application must work on their potato because they have disabled all features but still want the functionality. You can't realistically cherry pick underlying software pieces like that. Rather than delivering a buggy software that works under a million different combinations of features and settings I will deliver a package of software that run predictably well on one or more predictable platforms. That is "the atom". You either take it all, or not at all. From my experience the average users tend to be perfectly happy and satisfied with that. They are almost always running with default options everywhere anyway. It's the GNU-enthusiast hacker-types (and I count myself in) that tend to throw a tantrum about their custom preferences and philosophical and technical objections.

pasbesoin 9y ago

I'm worried about the intersection with EME and DRM. No more open web. And the crap will become inextricably intertwined with the content of value. Right now, it's "for content." There is going to be enormous commercial pressure to make it "for everything". We should start reconsidering the term "user agent".