I'd like to have some feedback from you. Do you agree with those points?
1) on most computers Javascript is enabled by default
2) This gives anyone a platform to play with parts of their owners equipment.
3) From a security point you are lost as soon as you give an adversary the opportunity to control your system.
4) Only non-active web content can guarantee that you keep control over your equipment.
And the last question: if all above is true, do we want to tell this to the public? Does it help? Or would we be seen as being completely paranoid.
Thanks, Matthias
Hi,
Am 2013-06-28 10:37, schrieb Matthias Kirschner:
- Only non-active web content can guarantee that you keep control over
your equipment.
And the last question: if all above is true, do we want to tell this to the public? Does it help? Or would we be seen as being completely paranoid.
The web today _is_ ECMAscript. Have a look at http://libreprojects.net
Best wishes Michael
Matthias Kirschner mk@fsfe.org writes:
- From a security point you are lost as soon as you give an adversary
the opportunity to control your system.
Well, javascript is run a restricted environment. I don't see how you'd be lost by running javascript. Also many universities let their students run code on their systems but I don't consider they have "lost".
- Only non-active web content can guarantee that you keep control over
your equipment.
There are security issues also in the code that parses this non-active content. Javascript is replacing a lot of things that used to be separate plugins with poor security track record.
On Fri, 28 Jun 2013 11:18, timo.lindfors@iki.fi said:
Well, javascript is run a restricted environment. I don't see how you'd be lost by running javascript. Also many universities let their students
To most users the browser is their window to the world and an alias for the computer. They don't understand that there is a difference. And web designers (or well, the marketing dept) try very hard to convince them that there is indeed no difference.
A box which automatically downloads all kind of binaries an runs them after they have passed a so-called virus checker, may also be considered a restricted environment. The restriction is in this case controlled by the virus checker and not the browser.
There are security issues also in the code that parses this non-active content. Javascript is replacing a lot of things that used to be separate plugins with poor security track record.
Plugins are installed by the user and not be data to be viewed. That makes a big difference:
- The user is enabled to control the code. - The plugin has a well defined behaviour and is not a volatile bunch of code. - A security audit of the plugin can be done.
Please, I don't want to hear a claim, that the JS code on web sites is secure because it is signed or distributed via a trusted (https) web site. PKIX (the X.509 based infrastructure used by https) is fucked up beyond all repair.
Shalom-Salam,
Werner
btw, no need to Cc: me since I'm on the list.
Werner Koch wk@gnupg.org writes:
To most users the browser is their window to the world and an alias for the computer. They don't understand that there is a difference. And web designers (or well, the marketing dept) try very hard to convince them that there is indeed no difference.
Agreed.
A box which automatically downloads all kind of binaries an runs them after they have passed a so-called virus checker, may also be considered a restricted environment. The restriction is in this case controlled by the virus checker and not the browser.
But surely virus checker is a blacklist and javascript isolation is more like a whitelist?
Plugins are installed by the user and not be data to be viewed. That makes a big difference:
- The user is enabled to control the code.
Well in most cases they are not since the plugins are non-free..
- The plugin has a well defined behaviour and is not a volatile bunch of code.
Not sure what this would mean, at least oracle java plugin updates try to trick users into installing ask toolbar:
http://www.zdnet.com/a-close-look-at-how-oracle-installs-deceptive-software-...
- A security audit of the plugin can be done.
See the point about non-free plugins :(
Please, I don't want to hear a claim, that the JS code on web sites is secure because it is signed or distributed via a trusted (https) web site. PKIX (the X.509 based infrastructure used by https) is fucked up beyond all repair.
I guess you need to define "secure" bit better here.
On Fri, 28 Jun 2013 13:34, timo.lindfors@iki.fi said:
btw, no need to Cc: me since I'm on the list.
[ Then please set an MFT header and my MUA will comply. That discussion is > 15 years old and we have since then a working solution.]
But surely virus checker is a blacklist and javascript isolation is more like a whitelist?
It is a blacklist: For example: The code loaded from external source may not open a file on user's host. A whitelist would cleary state what the code is allowed to do. But then it wouldn't be a useful language anymore.
- The user is enabled to control the code.
Well in most cases they are not since the plugins are non-free..
We are talking about security and thus free or non-free is just one data point to evaluate whether it is secure. Even a non-free plugin may be considered secure in some organizations. But right, free software is much more useful in this regard.
- The plugin has a well defined behaviour and is not a volatile bunch of code.
Not sure what this would mean, at least oracle java plugin updates try to trick users into installing ask toolbar:
That is a feature which needs to be evaluated during the audit. There pros and cons for automated updated. But even such automated updates are standard in that they have a defined version with the same code at all sites. That can't be guaranteed by the usual use of JS which commonly comes from a whole bunch of sites (and the reason why it is virtually impossible to not use google).
- A security audit of the plugin can be done.
See the point about non-free plugins :(
That usually makes the audit easy: We can't audit it thus it shall not be used.
Please, I don't want to hear a claim, that the JS code on web sites is secure because it is signed or distributed via a trusted (https) web site. PKIX (the X.509 based infrastructure used by https) is fucked up beyond all repair.
I guess you need to define "secure" bit better here.
Here in the sense that it is a well defined set of code which comes with a signature and can be tracked back to an audit or a trusted source. it can't: MitM attack on PKIX are commonplace. Does anyone really believe that the NSA has no means to ask another secret service to have one of their national CAs issue a malicious certificate? Come on: That system has been corrupted by the PKI business ever since. Nobody can expect that they ever withstood requests from the slouch hats.
Salam-Shalom,
Werner
Werner Koch wk@gnupg.org writes:
[ Then please set an MFT header and my MUA will comply. That discussion is > 15 years old and we have since then a working solution.]
[ Sorry but I have no idea how to do that. However, I added "reply to list" support to gnus a few years ago, it might be useful even if you don't want to use it: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627516 ]
It is a blacklist: For example: The code loaded from external source may not open a file on user's host. A whitelist would cleary state what the code is allowed to do. But then it wouldn't be a useful language anymore.
My system has always had a webcam but javascript only got to access it when chromium implemented support for it. You might call this a blacklist but at least to me it's looks like a whitelist. Wikipedia is not a good reference but http://en.wikipedia.org/wiki/JavaScript does talk about "granting privileges" which also would imply whitelist and not blacklist :/
See the point about non-free plugins :(
That usually makes the audit easy: We can't audit it thus it shall not be used.
Unfortunately the reality is that it does get used.
Here in the sense that it is a well defined set of code which comes with a signature and can be tracked back to an audit or a trusted source. it can't: MitM attack on PKIX are commonplace. Does anyone really believe that the NSA has no means to ask another secret service to have one of their national CAs issue a malicious certificate? Come on: That system has been corrupted by the PKI business ever since. Nobody can expect that they ever withstood requests from the slouch hats.
No comment ;-)
On Fri, 28 Jun 2013 23:27, timo.lindfors@iki.fi said:
[ Sorry but I have no idea how to do that. However, I added "reply to list" support to gnus a few years ago, it might be useful even if you don't want to use it:
Well, the you should know the manual page ;-) It all depends on whether everyone keeps a list of subscribed lists. I do have this list in message-subscribed-addresses.
talk about "granting privileges" which also would imply whitelist and not blacklist :/
Let's say it is a greylist or in the worst case a graylist ;-)
Salam-Shalom,
Werner
- on most computers Javascript is enabled by default
I doubt more than a handful people disable it.
- This gives anyone a platform to play with parts of their owners
equipment.
This is not clearly expressed. Who is anyone and who is owner and what is equipment? The owner of a cellphone is the manufacturer (you, Matthias, told us), so the sentence is unclear.
[ok, that's what I wanted to say, the rest is irrelevant, but I already wrote it]
- From a security point you are lost as soon as you give an adversary
the opportunity to control your system.
I can't evaluate, I don't know javescript. I used to run Tcl, and the "safe" environment in there is well designed. I *hope* all technology is designed as well as Tcl was (recent versions are worse, imho).
But even if it is safe, it can use your processing power at will, for sure.
- Only non-active web content can guarantee that you keep control over
your equipment.
Lapalisse. Data is data, and code is code. If you think to access data and you are unexpectedly executing code, you have a problem. At least *I* have a problem. And a few losers like me. However, malware mostly exists because expectedly-data is executed instead ("do not *open* untrusted email" is the solution, they say).
And the last question: if all above is true, do we want to tell this to the public? Does it help? Or would we be seen as being completely paranoid.
It is true (modulo my ignorance of javascript), we don't want to tell, because it would be seen as paranoid. The tech world is way beyond this. Pursuing a loosing attitude, like I find myself doing every day, is, well... loosing.
/alessandro
On 28/06/13 10:18, Alessandro Rubini wrote:
It is true (modulo my ignorance of javascript), we don't want to tell, because it would be seen as paranoid. The tech world is way beyond this.
"# Keep Flash, Java and JavaScript disabled in your web browser, except for sites that really need it." -- Andrew Ludgate, Sophos (proprietary anti-virus vendor)
I'm sure you can find many more experts offering similar advice.
It's mainly those with some interest in javascript, like browser makers and hipster website developers who, are "way beyond this", not the tech world.
I'd love it if we shared good practice and encourage people to install things like noscript.net.
On my (CyanogenMod10 and f-droid) phone, I have two browsers: one with javascript that I use for a few web apps that don't work without it (including one of the telco ones, annoyingly!); plus one with scripts switched off. That's worth it, isn't it?
Regards,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I do the same on my laptop: chromium for day to stuff I don't care about and a (fairly) locked-down IceCat for the important stuff.
And I agree: the more people use NoScript, the better. Maybe we could put together some kind of "best practices" site - that goes into slightly more depth than Prism Break? I'd be happy to work on that content as I'm not much of a developer.
Wes
On 28/06/13 11:06, MJ Ray wrote:
On 28/06/13 10:18, Alessandro Rubini wrote:
It is true (modulo my ignorance of javascript), we don't want to tell, because it would be seen as paranoid. The tech world is way beyond this.
"# Keep Flash, Java and JavaScript disabled in your web browser, except for sites that really need it." -- Andrew Ludgate, Sophos (proprietary anti-virus vendor)
I'm sure you can find many more experts offering similar advice.
It's mainly those with some interest in javascript, like browser makers and hipster website developers who, are "way beyond this", not the tech world.
I'd love it if we shared good practice and encourage people to install things like noscript.net.
On my (CyanogenMod10 and f-droid) phone, I have two browsers: one with javascript that I use for a few web apps that don't work without it (including one of the telco ones, annoyingly!); plus one with scripts switched off. That's worth it, isn't it?
Regards,
Wes Packer mail@wespacker.me.uk writes:
And I agree: the more people use NoScript, the better. Maybe we could put together some kind of "best practices" site - that goes into slightly more depth than Prism Break? I'd be happy to work on that content as I'm not much of a developer.
I'd rather promote free software web applications than take a position against all web applications.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
That's what I meant. Prism break is great but maybe a site that goes into a lot more detail about how to install and use these Free alternatives. The information is out there but a "one-stop-shop" might be convenient?
On 28/06/13 11:45, Timo Juhani Lindfors wrote:
Wes Packer mail@wespacker.me.uk writes:
And I agree: the more people use NoScript, the better. Maybe we could put together some kind of "best practices" site - that goes into slightly more depth than Prism Break? I'd be happy to work on that content as I'm not much of a developer.
I'd rather promote free software web applications than take a position against all web applications. _______________________________________________ Discussion mailing list Discussion@fsfeurope.org https://mail.fsfeurope.org/mailman/listinfo/discussion
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Sorry, I forgot to mention: NoScript allows for control of script on a site-by-site basis so it's not an indiscriminate script blocker. Works well, I've found.
Wes
On 28/06/13 11:45, Timo Juhani Lindfors wrote:
Wes Packer mail@wespacker.me.uk writes:
And I agree: the more people use NoScript, the better. Maybe we could put together some kind of "best practices" site - that goes into slightly more depth than Prism Break? I'd be happy to work on that content as I'm not much of a developer.
I'd rather promote free software web applications than take a position against all web applications. _______________________________________________ Discussion mailing list Discussion@fsfeurope.org https://mail.fsfeurope.org/mailman/listinfo/discussion
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Does it? That sucks.
Ours wouldn't ;-)
Wes
On 28/06/13 12:06, Werner Koch wrote:
On Fri, 28 Jun 2013 12:32, mail@wespacker.me.uk said:
slightly more depth than Prism Break? I'd be happy to work on that
Which uses JS to switch languages and track the user; why?
Shalom-Salam,
Werner
Werner Koch wk@gnupg.org wrote:
On Fri, 28 Jun 2013 12:32, mail@wespacker.me.uk said:
slightly more depth than Prism Break? I'd be happy to work on that
Which uses JS to switch languages and track the user; why?
How a language switch script tracks you?
Anyway, making an official statement for rejecting javascript completely seems like neo-Luddism to me.
It would make more sense to promote Free Software Add-ons (like disconnect.me) that help you block javascript code that tracks you.
On 06/28/2013 07:50 PM, Nikos Roussos wrote:
It would make more sense to promote Free Software Add-ons (like disconnect.me) that help you block javascript code that tracks you.
That is much better as in general terms, JavaScript is not bad. You can do a lot good things with it, e.g. AJAX-enhanced (a noscript-version should always be provided) websites.
Best regards, Roland
Nikos Roussos comzeradd@fsfe.org a écrit :
Werner Koch wk@gnupg.org wrote:
On Fri, 28 Jun 2013 12:32, mail@wespacker.me.uk said:
slightly more depth than Prism Break? I'd be happy to work on that
Which uses JS to switch languages and track the user; why?
How a language switch script tracks you?
Anyway, making an official statement for rejecting javascript completely seems like neo-Luddism to me.
It would make more sense to promote Free Software Add-ons (like disconnect.me) that help you block javascript code that tracks you.
Discussion mailing list Discussion@fsfeurope.org https://mail.fsfeurope.org/mailman/listinfo/discussion
We should check. I have been told disconnect.me has not published their source code in a while....
Sorry for diverging.
On Fri, 2013-06-28 at 22:11 +0200, Hugo Roy wrote:
Nikos Roussos comzeradd@fsfe.org a écrit :
Werner Koch wk@gnupg.org wrote:
On Fri, 28 Jun 2013 12:32, mail@wespacker.me.uk said:
slightly more depth than Prism Break? I'd be happy to work on that
Which uses JS to switch languages and track the user; why?
How a language switch script tracks you?
Anyway, making an official statement for rejecting javascript completely seems like neo-Luddism to me.
It would make more sense to promote Free Software Add-ons (like disconnect.me) that help you block javascript code that tracks you.
We should check. I have been told disconnect.me has not published their source code in a while....
Sorry for diverging.
I haven't check its code, but the latest commit seems recent.
On Fri, 28 Jun 2013 19:50, comzeradd@fsfe.org said:
Which uses JS to switch languages and track the user; why?
How a language switch script tracks you?
Not the part which is responsible for language switching but the one which sends data back to their analytics code. Noscript marked the site as JS driven and thus I checked the source as always. The good thing is that the particular web page is actually readable.
Shalom-Salam,
Werner
On 06/28/2013 12:06 PM, MJ Ray wrote:
On 28/06/13 10:18, Alessandro Rubini wrote:
It is true (modulo my ignorance of javascript), we don't want to tell, because it would be seen as paranoid. The tech world is way beyond this.
"# Keep Flash, Java and JavaScript disabled in your web browser, except for sites that really need it." -- Andrew Ludgate, Sophos (proprietary anti-virus vendor)
I'm sure you can find many more experts offering similar advice.
It's mainly those with some interest in javascript, like browser makers and hipster website developers who, are "way beyond this", not the tech world.
I'd love it if we shared good practice and encourage people to install things like noscript.net.
There is a problem with that, though: Web designers nowadays want to create a user experience based on the desktop-like interactivity provided by Ajax. This requires Javascript, and this means that very many web applications are designed which require JavaScript. To the extent that it's a security problem the solution might be improved sandboxing, because I don't think the demand for that kind of interfaces is going to go away.
br Carsten
On 28/06/13 11:36, Carsten Agger wrote:
MJ Ray wrote:
I'd love it if we shared good practice and encourage people to install things like noscript.net.
There is a problem with that, though: Web designers nowadays want to create a user experience based on the desktop-like interactivity provided by Ajax. This requires Javascript, and this means that very many web applications are designed which require JavaScript. To the extent that it's a security problem the solution might be improved sandboxing, because I don't think the demand for that kind of interfaces is going to go away.
Will sandboxing ever be improved enough? It's been 18 years already.
I've some hope though: I really liked eating lots of chocolate for many years, but I discovered I'm intolerant of an ingredient in it and it was causing me pain, so I soon rejected it.
People really like eating lots of javascript, but once they discover that it's a huge attack vector for security problems and causes them pain, they may be a bit more discerning. Hopefully, they will start to reject the incompetent web developers and/or site owners who slam the door in users' faces if they don't have javascript enabled indiscriminately even when they're not doing anything that requires it.
Yes, javascript will be needed for some tasks, but it's currently demanded (and permitted) far too widely. That should change and I believe the universe will reward our honesty if we advise people to only permit javascript when you trust the website.
What do we gain by hiding this inconvenient security *and freedom* problem from our friends? Won't they think we're just like all the others who would rather make it easier for people to develop whiz-bang apps than help our friends take control of their computers?
Regards,
On Fri, 28 Jun 2013 12:06, mjr@phonecoop.coop said:
I'd love it if we shared good practice and encourage people to install things like noscript.net.
The problem with noscript is that you need to add temporary exceptions way to often. It is a good tool, nevertheless.
But better also run your browser under a different account and a second X server or with Xephyr. Coping and pasting lacks quite some comfort then but that is the price to be a little bit safer.
Salam-Shalom,
Werner
On 06/28/2013 07:02 AM, Werner Koch wrote:
On Fri, 28 Jun 2013 12:06, mjr@phonecoop.coop said:
I'd love it if we shared good practice and encourage people to install things like noscript.net.
The problem with noscript is that you need to add temporary exceptions way to often. It is a good tool, nevertheless.
But better also run your browser under a different account and a second X server or with Xephyr. Coping and pasting lacks quite some comfort then but that is the price to be a little bit safer.
Javascript is the future of the web, it makes no sense to fight it, it has already won, but it is not all for the worst.
Major browser have good sandboxing technology and their security is improved every day.
However should you not trust your browser and/or some website you want to visit, then you can run OS level sandoboxing. I do it this way:
sandbox -i $HOME/.mozilla/extensions -i $HOME/.mozilla/plugins -i $HOME/.mozilla/firefox/abcdefgh.sandbox -i $HOME/.mozilla/firefox/profiles.ini -w 1024x900 -t sandbox_web_t -M -X /usr/bin/firefox -P sandbox $*
It requires at least a basic SeLinux Policy installed and the sandbox program, but it is really neat in that it completely isolates the browser and crates a completely new environment for it to run. The template you start from is copied from the referenced template and superimposed via name spaceing, and the binary itself is prevented access to anything in the user's home directory. This also means that any configuration change is lost on closing it, but that is intentional as it will erase any change an exploit may attempt to make as well.
Simo.
Simo Sorce s@ssimo.org writes:
sandbox -i $HOME/.mozilla/extensions -i $HOME/.mozilla/plugins -i $HOME/.mozilla/firefox/abcdefgh.sandbox -i $HOME/.mozilla/firefox/profiles.ini -w 1024x900 -t sandbox_web_t -M -X /usr/bin/firefox -P sandbox $*
It requires at least a basic SeLinux Policy installed and the sandbox program, but it is really neat in that it completely isolates the browser and crates a completely new environment for it to run.
Can't the browser still talk anything it wants with the X server? Or does your X server somehow understand selinux labels?
On Tue, 2013-07-02 at 11:24 +0300, Timo Juhani Lindfors wrote:
Simo Sorce s@ssimo.org writes:
sandbox -i $HOME/.mozilla/extensions -i $HOME/.mozilla/plugins -i $HOME/.mozilla/firefox/abcdefgh.sandbox -i $HOME/.mozilla/firefox/profiles.ini -w 1024x900 -t sandbox_web_t -M -X /usr/bin/firefox -P sandbox $*
It requires at least a basic SeLinux Policy installed and the sandbox program, but it is really neat in that it completely isolates the browser and crates a completely new environment for it to run.
Can't the browser still talk anything it wants with the X server? Or does your X server somehow understand selinux labels?
sandbox -X runs everything into a nested X server (Xephyr here) run explicitly for the application, so that the app does not have direct access to the outer X server.
Although there was a feature (XACE) to make the X server more secure I do no think it ever worked well enough. I think the only good solution will be to use wayland once it is good enough. Its model isolates each process and is much better from a security pov from what I've been told so far.
Simo.
simo s@ssimo.org writes:
sandbox -X runs everything into a nested X server (Xephyr here) run explicitly for the application, so that the app does not have direct access to the outer X server.
Interesting, I'd like to try that out and evaluate its security and usability. I can't find "sandbox" binary in Debian, is it perhaps under some other name or should I build it from source?
Although there was a feature (XACE) to make the X server more secure I do no think it ever worked well enough. I think the only good solution will be to use wayland once it is good enough. Its model isolates each process and is much better from a security pov from what I've been told so far.
Indeed. The only working models that I have seen are Qubes OS and just using xpra/vnc with virtual machine/another user.
-Timo
The sandbox binary on debian was patched out of the package, as "not being ready" in some way.
See: http://unix.stackexchange.com/questions/67127/how-do-i-install-selinuxs-sand...
On Wed, Jul 3, 2013 at 7:28 AM, Timo Juhani Lindfors timo.lindfors@iki.fiwrote:
simo s@ssimo.org writes:
sandbox -X runs everything into a nested X server (Xephyr here) run explicitly for the application, so that the app does not have direct access to the outer X server.
Interesting, I'd like to try that out and evaluate its security and usability. I can't find "sandbox" binary in Debian, is it perhaps under some other name or should I build it from source?
Although there was a feature (XACE) to make the X server more secure I do no think it ever worked well enough. I think the only good solution will be to use wayland once it is good enough. Its model isolates each process and is much better from a security pov from what I've been told so far.
Indeed. The only working models that I have seen are Qubes OS and just using xpra/vnc with virtual machine/another user.
-Timo _______________________________________________ Discussion mailing list Discussion@fsfeurope.org https://mail.fsfeurope.org/mailman/listinfo/discussion
On 28/06/13 12:02, Werner Koch wrote:
The problem with noscript is that you need to add temporary exceptions way to often. It is a good tool, nevertheless.
I think most of that is thanks to javascript authors who just include external libraries from many other domains without a thought for the performance (more DNS lookups, less request pipelining possible) and security (what if a registrant loses a domain?) implications.
But better also run your browser under a different account and a second X server or with Xephyr. Coping and pasting lacks quite some comfort then but that is the price to be a little bit safer.
I do that for a few very sensititive websites. Copy-paste lacks comfort? Is it even possible?
Thanks,
On Sat, 29 Jun 2013 16:47, mjr@phonecoop.coop said:
I do that for a few very sensititive websites. Copy-paste lacks comfort? Is it even possible?
xclip is a simple tool to patse between different X servers,
Salam-Shalom,
Werner
Matthias Kirschner mk@fsfe.org wrote:
I'd like to have some feedback from you. Do you agree with those points?
- on most computers Javascript is enabled by default
It's enabled by default in most browsers, but lots of embedded computers don't have browsers (or browser-independent JavaScript implementations) installed.
- This gives anyone a platform to play with parts of their owners
equipment.
Not anyone, "only" anyone who controls a website the browser accepts JavaScript from or is able to modify the traffic.
- From a security point you are lost as soon as you give an adversary
the opportunity to control your system.
At least in theory the JavaScript provider's control over the owner's system is limited by the "sandbox".
Given the poor security track record of all JavaScript implementations executing JavaScript from untrustworthy sources certainly makes the system less secure, though.
- Only non-active web content can guarantee that you keep control over
your equipment.
"Non-active web content" tends to cause a lot less security problems than "active content", but that's about it.
And the last question: if all above is true, do we want to tell this to the public? Does it help? Or would we be seen as being completely paranoid.
I think at first the FSFE should make sure that its own website properly works without JavaScript enabled. A good start would be fixing or ditching EtherPad whose developers apparently don't care about accessibility.
Fabian
Hi,
Am 2013-06-28 13:10, schrieb Fabian Keil:
And the last question: if all above is true, do we want to tell this to the public? Does it help? Or would we be seen as being completely paranoid.
I think at first the FSFE should make sure that its own website properly works without JavaScript enabled. A good start would be fixing or ditching EtherPad whose developers apparently don't care about accessibility.
You're mixing up things: The FSFE website per se shouldn't require JS at all. Tools like etherpad are really useful and I don't think they can be implemented without a certain amount of JS at the moment. That etherpad isn't accessible is a shame, but I think it's not a restriction of JS per se.
Best wishes Michael
On Fri, 28 Jun 2013 13:27, mkesper@schokokeks.org said:
Tools like etherpad are really useful and I don't think they can be implemented without a certain amount of JS at the moment.
Why not implement it as a regular application without the need for a browser? It is not harder to install than an app on your phone ("apt-get install etherpad"). And if the developers like, they may still use JS as the implementation language. That would be very different from using downloaded JS.
Writing portable applications is really easy. There are only three mainstream OSes these days.
Shalom-Salam,
Werner
Michael Kesper mkesper@schokokeks.org wrote:
Am 2013-06-28 13:10, schrieb Fabian Keil:
And the last question: if all above is true, do we want to tell this to the public? Does it help? Or would we be seen as being completely paranoid.
I think at first the FSFE should make sure that its own website properly works without JavaScript enabled. A good start would be fixing or ditching EtherPad whose developers apparently don't care about accessibility.
You're mixing up things: The FSFE website per se shouldn't require JS at all.
I'm not sure what I'm supposed to be mixing up. Are you saying EtherPad isn't part of the FSFE website?
Tools like etherpad are really useful and I don't think they can be implemented without a certain amount of JS at the moment.
Allowing users to read and modify a text with a browser isn't rocket science and doesn't require JavaScript.
That etherpad isn't accessible is a shame, but I think it's not a restriction of JS per se.
Of course it's not a restriction of JavaScript per se but the result of EtherPad not being designed to work without JavaScript.
I'm not saying the user experience with and without JavaScript has to be exactly the same, but apparently recent EtherPad versions even require JavaScript to read the text.
Fabian
2013/6/29 Fabian Keil freebsd-listen@fabiankeil.de:
Tools like etherpad are really useful and I don't think they can be implemented without a certain amount of JS at the moment.
Allowing users to read and modify a text with a browser isn't rocket science and doesn't require JavaScript.
Come one, Etherpad does much more than simply read and modify text, and what it does can certainly not be done without JavaScript.
I think that the success of HTML5 and related technologies is great. I really seems to have lead us out of the Microsoft lock-in world and thanks to the early vice decisions on open standards and Free Software the web is both technically, culturally and legaly a much more open place than any of it's competitor. The web is not perfect and it is still possible to publish proprietary programs with closed down and obfuscated JavaScript code, but still, it is much better than the competition in many regards.
I am not afraid of JavaScript. If we look at the security record of many browser related technologies, almost all security issues where somebody has managed to privilege them self up to the OS level from the browser sandbox has been related to Active X, Java applets or Flash. I don't allow my browser to automatically execute any of these, and with Flashblock I control case-by-case when it is allowed. I don't block JavaScript and I am not afraid of it. I've been doing web apps coding JS both on the server side and client side for many years and I've never come across any method to escape the browser sandbox, all security issues I know are related to over-consuming resources and service denial, cross-site scripting and traditional user-assisted attacks. All of these have effective counter measures already and e.g. cross-site post attacks can be done even without JS if the website developer was clueless.
As Free Software supporters our biggest threats are the dominance of Microsoft Office and their file formats with network effects, the pre-installed Windows monopoly and source code hiding app stores on mobile and desktop platforms. The success of HTML5 and friends automatically helps defeat these and if we start campaigning against JavaScript, we'll just end up helping closed app store ecosystems and old monopolies.
Also in your discussion you seem to value security features out-of-context. Security is always a trade-off between what you gain and what you loose. If you want maximum security you can shut off your computer or disconnect it from any networks, but that isn't the point.
The question here should be is it better to run apps locally or via the browser? The simple answer to this is that it depends on what the application does. In most cases if you are developing new end-user software I'd recommend the browser based approach, simply because that is the only way you'll get a truly cross-platform usable app.
-- Otto Kekäläinen [] otto@fsfe.org Finnish Team Coordinator [][][] finland@fsfe.org Free Software Foundation Europe || +358 44 566 2204 Support FSFE! http://fsfe.org/support?otto
On 29/06/13 14:10, Otto Kekäläinen wrote:
I am not afraid of JavaScript. If we look at the security record of many browser related technologies, almost all security issues where somebody has managed to privilege them self up to the OS level from the browser sandbox has been related to Active X, Java applets or Flash.
Is the above true? It certainly goes against the impression I get from sites like http://nakedsecurity.sophos.com even if some of them are using javascript to trigger other types of attacks like user-assisted ones where they make things look like a legitimate-but-confusing system request.
But please remember, almost no-one is suggesting campaigning against all javascript - just that users should be given more control with good free software like noscript.
Hope that explains,
On Fri, 28 Jun 2013 10:37, mk@fsfe.org said:
And the last question: if all above is true, do we want to tell this to the public? Does it help? Or would we be seen as being completely paranoid.
It is not paranoid but a campaign would call the majority of pro-JS-web-designer in action. Thus better come up with that idea slowly.
Salam-Shalom,
Werner
At Fri, 28 Jun 2013 10:37:44 +0200, Matthias Kirschner wrote:
I'd like to have some feedback from you. Do you agree with those points?
on most computers Javascript is enabled by default
This gives anyone a platform to play with parts of their owners
equipment.
- From a security point you are lost as soon as you give an adversary
the opportunity to control your system.
- Only non-active web content can guarantee that you keep control over
your equipment.
I strongly disagree. Any data that is interpreted has the potential to take control of the interpreter. This is true not only of JavaScript, but also of OpenOffice.org XML, PDF and FAT. Since we clearly want to read documents from people we don't trust (e.g., the NSA), then we need to design our systems and our programs to not only make it hard for data to do something (as opposed to be!) malicious, but to limit the potential damage should it succeed. This firstly requires educating developers, not users. Of course, it would be nice if the systems made this easier. For instance, whereas it is easy to drop your user id on the Hurd, this is not possible on Linux. The closest you can come is to dynamically create a new user, but this requires superuser privileges or some mediator like Plash, which is unfortunately no longer maintained.
Neal
On Fri, Jun 28, 2013 at 10:37:44AM +0200, Matthias Kirschner wrote:
I'd like to have some feedback from you. Do you agree with those points?
- on most computers Javascript is enabled by default
In the next version of Firefox they even want to remove the option to disable JavaScript! http://limi.net/checkboxes-that-kill/
I'm also torn on this topic. On the one hand I'm fascinated on what you can do with JavaScript - on the other hand that makes me really nervous.
You know how the saying goes: Why is a sandbox called "sandbox"? ... Because only little children believe in it.
Another issue you haven't mentioned yet is, that most of it is unfree software that runs on the computer of the users. I mean you have even less control over it than with proprietary software. With proprietary software the user actively decides to install it, and once installed, nobody can change it or take it away. That is different with JavaScript...
In the beginning JavaScript was just benign simple scripts, but today that can be large software. The package "emscripten" is a compiler, that compiles C and C++ to JavaScript. Look at the demoes, what that can already do today: https://github.com/kripken/emscripten/wiki
It is so fascinating - and yet so frightening!
"Andreas K. Foerster" list@akfoerster.de writes:
Another issue you haven't mentioned yet is, that most of it is unfree software that runs on the computer of the users.
I again think that I'd much rather support free web applications than try to lobby against web applications in general. It's just a computing model similar to thin clients. Often it's also much easier to get the general population to start using a free software web application than to get them to use a free software native application.
Hi,
Timo Juhani Lindfors timo.lindfors@iki.fi schrieb:
I again think that I'd much rather support free web applications than try to lobby against web applications in general. It's just a computing model similar to thin clients. Often it's also much easier to get the general population to start using a free software web application than to get them to use a free software native application.
And it's possible to break free from "app prisons" via web applications.
Best wishes Michael
Hi Matthias!
Am Freitag, 28. Juni 2013, 10:37:44 schrieb Matthias Kirschner:
I'd like to have some feedback from you. Do you agree with those points?
- on most computers Javascript is enabled by default
Most stats say so!
- This gives anyone a platform to play with parts of their owners
equipment.
As already stated in this thread, every document that's opened on a computer, uses its resources. It doesn't matter if you open HTML or HTML with JS or an ODT.
- From a security point you are lost as soon as you give an adversary
the opportunity to control your system.
As I said in 2) its irrelevant, what gets interpreted. I would further say, that JavaScipt is very much in the focus of many people regarding to security. Plain HTML or odt or txt or png might not be.
- Only non-active web content can guarantee that you keep control over
your equipment.
Don't agree. I can create pretty non-active pages that might crash your browser just by overusing resources. Most browser act very badly in this case. I am not sure if that crash is usable as attack vector, somebody might analyze.
And the last question: if all above is true, do we want to tell this to the public? Does it help? Or would we be seen as being completely paranoid.
Not paranoid enough when it comes to tracking [1].
I think there are problems regarding to web applications. Often licensing is not done properly, so much code, especially javascript code is put out unlicensed although the creator wanted it to be free. Tell them about free software licenses [2].
Modern Web applications aren't possible without JavaScript, take that for granted. But there is an elephant in the room. Ever thought about who controls the infrastructure behind most web services? The backend code? For most services there is no competition in hosting, because the backend is not free. Further in many services the user is the product. Because of that, the service is usable at no charge.
So we should concentrate on alternatives for cloud services that are either self hostable and/or at least hosted by more than one provider. Users should be made aware of the fact, that hosting of cloud services costs a lot of money. They are the product, unless they pay for it with money. Some kind of privacy admiring hosting provider charter would be fine too.
Best! Christian
[1] https://panopticlick.eff.org/ [2] http://www.theregister.co.uk/2013/04/18/github_licensing_study/
Thank you all for your valuable feedback on this! I will think a bit about it.
Regards, Matthias