4 ms·

> (a) If large amounts of code written in memory unsafe languages is such a concern then Mozilla should immediately stop adding large numbers of highly complex

> (a) If large amounts of code written in memory unsafe languages is such a concern then Mozilla should immediately stop adding large numbers of highly complex new features implemented in unsafe code to Firefox every year, > (b) ... mostly to do things that have absolutely nothing to do with displaying web pages but are enabled by default for political reasons. (a) Mozilla is working on adding/replacing parts of Firefox with a language emphasizing security (among other things). First Rust push in Firefox landed a Rust mp4 parser [1], on 2015-06-17. Others will come; in the meantime, the world keeps turning, and users / web. developers expect these new web features, which Moz devs implement with the infrastructure they have and know. They're not going to cross their hands and declare a moratorium until Rust (or other security-mitigating features/changes) are fully integrated. (b) Not sure what you mean by political reasons and maybe you want to stay stuck in 1992, but I don't, and like many users I do want "webgl, webrtc, webfonts, webm, websockets, new css features and so on" . EDIT I'd have added "You can install links if you want a simple browser letting you read static html documents", which you would have answered with "But I can't, every website require these features now", to which I'd have answered "a. Yeah, not everyone (that's an understatement) does progressive enhancement, but ultimately b. The times they are a-changing" [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1175322 https://bugzilla.mozilla.org/show_bug.cgi?id=1175322

baghira 11y ago
It doesn't help your position the fact that you are unable to express it without belittling anybody who disagrees with you using stuff like "stay stuck in 1992" ("If you don't like America you should go to Russia!"). Also, the links/lynx jokes have really gotten tired, plenty of people browse the web with ublock, no(t)script, webgl and webrtc disabled and so on. The pretense that anybody who tries to retain a modicum of control on what its browser does and does not it a luddist is frankly irritating. And the whole language debate is completely off point, we have plenty of safe(r) languages for writing stuff, the misguided idea is that the only way to do so is to use javascript and stick the resulting program inside the browser.
- ronjouch 11y ago
  > It doesn't help your position the fact that you are unable to express it without belittling anybody who disagrees with you using stuff like "stay stuck in 1992" ("If you don't like America you should go to Russia!"). True, that was useless, could have just said "I and many users do want these features" . Thanks, and sorry anon. > the links/lynx jokes have really gotten tired, plenty of people browse the web with ublock, no(t)script, webgl and webrtc disabled and so on. The pretense that anybody who tries to retain a modicum of control on what its browser does and does not it a luddist is frankly irritating. That wasn't a links joke, I could have phrased it with your own words "You can install ublock, no(t)script, and disable webgl/webrtc if you want a simple browser letting you read static html documents" , and "But I can't, every website require these features now" would still be an answer. My conclusion isn't that "anyone trying to retain a modicum of control on what its browser does and does not is a luddist" --and I do use some of these extensions too--, it's that the barebones web experience anon wants is broken now (and probably forever), due to: a. Sadly, non-respect of progressive enhancement in cases where it's possible (documents). b. The fact that _some_ parts of the web are increasingly not documents, but whole apps whose progressive-enhancement baseline (running without all the bells and whistles) would do nothing because they depend on these features. > And the whole language debate is completely off point, we have plenty of safe(r) languages for writing stuff, the misguided idea is that the only way to do so is to use javascript and stick the resulting program inside the browser. Yes. Development practices, testing, fuzzing, and safe(r) languages, like Rust.
  - baghira 11y ago
    Ok, I guess that I misread the tone of your post (i.e. we largely agree). I don't however think that the web it that broken without those features (javascript being the harder one to police). Judging from the browsing habits of my family members, they don't spend nearly as much time inside web applications as the HN news cycle would lead me to believe: some news sites, some webmail (and even there, when presented with a decent looking mail application they happily switched), the most basic functions of facebook, and "utilities" i.e. web banking, traveling, university websites. None of these uses requires the ability to play quake3 inside firefox, or are really applications inside a webpage. Same probably goes for all the browsers in the workplace, for instance. I'll agree with you that few sites will do progressive-enhancement (and decent accessibiliy), I'm just disappointed in the defeatist attitude of browser vendors and expert users: the idea of having a browser safe mode that you can lock down doesn't strike me as such an impossiblity and it would give some incentive to developers to put their act together.
anon1385 11y ago
>Mozilla is working on adding/replacing parts of Firefox with a language emphasizing security (among other things). The safety of the implementation language is far from the only concern when considering the security impact of modern browser features. The recent WebRTC issues are well documented, as was the HSTS 'supercookies' issue. Even something seemingly fairly innocuous like css keyframe animation can be used to do remote timing attacks without js to leak browser state such as browsing history[1]. SVG filters in Firefox allowed information to be read from arbitrary pages through timing attacks, till they removed some of the optimisations[2]. Those kinds of things are not solvable with a safer language (in some cases that probably makes fixing timing attacks more difficult/impossible). I'm sure there are more of these kinds of things to be found. Some of them are realistically never going to be fixed now because they are baked into the standards and the browser vendors clearly care more about animating gizmos and not breaking existing sites than leaking users browser state. [1] https://www.nds.rub.de/media/nds/veroeffentlichungen/2014/07/09/DSN_paper.pdf https://www.nds.rub.de/media/nds/veroeffentlichungen/2014/07... [2] http://www.contextis.com/documents/2/Browser_Timing_Attacks.pdf http://www.contextis.com/documents/2/Browser_Timing_Attacks.... and https://www.mozilla.org/en-US/security/advisories/mfsa2013-55/ https://www.mozilla.org/en-US/security/advisories/mfsa2013-5... Read the bug to see how difficult it was for the devs to fix the issues without making the feature unusable - it took years >I'd have added "You can install links if you want a simple browser letting you read static html documents", which you would have answered with "But I can't, every website require these features now", to which I'd have answered "a. Yeah, not everyone (that's an understatement) does progressive enhancement, but ultimately b. The times they are a-changing" I'm not concerned about myself. I disable stuff like WebGL that I don't use, and I block most Javascript etc etc. My concern is for the average user who has absolutely no idea these features even exist, never mind knowing which ones they can turn off without breaking the sites they use. The general insecurity of the web affects me (and everybody else). When a site gets hacked because one of the admins was exploited by a browser vulnerability and my details get leaked that affects me.
- ronjouch 11y ago
  > The safety of the implementation language is far from the only concern when considering the security impact of modern browser features. [...] Those kinds of things are not solvable with a safer language (in some cases that probably makes fixing timing attacks more difficult/impossible). I'm sure there are more of these kinds of things to be found. Some of them are realistically never going to be fixed now because they are baked into the standards and the browser vendors clearly care more about animating gizmos and not breaking existing sites than leaking users browser state. Good points, didn't know about the SVG exploit having taken so long. Rust (which, as you say, is no silver bullet) is one data point showing Mozilla's commitment to security, but the variance in the time to fixing exploits is worth consideration. Today's exploit was fixed in one day, SVG took 18 months. Why? Did Moz do a good job at prioritizing based on the severity / availability of exploits in the wild, or was the long time to SVG fix just caused by technical difficulties? I don't know, maybe a mozillian involved can comment.

baghira 11y ago

It doesn't help your position the fact that you are unable to express it without belittling anybody who disagrees with you using stuff like "stay stuck in 1992" ("If you don't like America you should go to Russia!"). Also, the links/lynx jokes have really gotten tired, plenty of people browse the web with ublock, no(t)script, webgl and webrtc disabled and so on. The pretense that anybody who tries to retain a modicum of control on what its browser does and does not it a luddist is frankly irritating. And the whole language debate is completely off point, we have plenty of safe(r) languages for writing stuff, the misguided idea is that the only way to do so is to use javascript and stick the resulting program inside the browser.

ronjouch 11y ago
> It doesn't help your position the fact that you are unable to express it without belittling anybody who disagrees with you using stuff like "stay stuck in 1992" ("If you don't like America you should go to Russia!"). True, that was useless, could have just said "I and many users do want these features" . Thanks, and sorry anon. > the links/lynx jokes have really gotten tired, plenty of people browse the web with ublock, no(t)script, webgl and webrtc disabled and so on. The pretense that anybody who tries to retain a modicum of control on what its browser does and does not it a luddist is frankly irritating. That wasn't a links joke, I could have phrased it with your own words "You can install ublock, no(t)script, and disable webgl/webrtc if you want a simple browser letting you read static html documents" , and "But I can't, every website require these features now" would still be an answer. My conclusion isn't that "anyone trying to retain a modicum of control on what its browser does and does not is a luddist" --and I do use some of these extensions too--, it's that the barebones web experience anon wants is broken now (and probably forever), due to: a. Sadly, non-respect of progressive enhancement in cases where it's possible (documents). b. The fact that _some_ parts of the web are increasingly not documents, but whole apps whose progressive-enhancement baseline (running without all the bells and whistles) would do nothing because they depend on these features. > And the whole language debate is completely off point, we have plenty of safe(r) languages for writing stuff, the misguided idea is that the only way to do so is to use javascript and stick the resulting program inside the browser. Yes. Development practices, testing, fuzzing, and safe(r) languages, like Rust.
- baghira 11y ago
  Ok, I guess that I misread the tone of your post (i.e. we largely agree). I don't however think that the web it that broken without those features (javascript being the harder one to police). Judging from the browsing habits of my family members, they don't spend nearly as much time inside web applications as the HN news cycle would lead me to believe: some news sites, some webmail (and even there, when presented with a decent looking mail application they happily switched), the most basic functions of facebook, and "utilities" i.e. web banking, traveling, university websites. None of these uses requires the ability to play quake3 inside firefox, or are really applications inside a webpage. Same probably goes for all the browsers in the workplace, for instance. I'll agree with you that few sites will do progressive-enhancement (and decent accessibiliy), I'm just disappointed in the defeatist attitude of browser vendors and expert users: the idea of having a browser safe mode that you can lock down doesn't strike me as such an impossiblity and it would give some incentive to developers to put their act together.

anon1385 11y ago

>Mozilla is working on adding/replacing parts of Firefox with a language emphasizing security (among other things). The safety of the implementation language is far from the only concern when considering the security impact of modern browser features. The recent WebRTC issues are well documented, as was the HSTS 'supercookies' issue. Even something seemingly fairly innocuous like css keyframe animation can be used to do remote timing attacks without js to leak browser state such as browsing history[1]. SVG filters in Firefox allowed information to be read from arbitrary pages through timing attacks, till they removed some of the optimisations[2]. Those kinds of things are not solvable with a safer language (in some cases that probably makes fixing timing attacks more difficult/impossible). I'm sure there are more of these kinds of things to be found. Some of them are realistically never going to be fixed now because they are baked into the standards and the browser vendors clearly care more about animating gizmos and not breaking existing sites than leaking users browser state. [1] https://www.nds.rub.de/media/nds/veroeffentlichungen/2014/07/09/DSN_paper.pdf https://www.nds.rub.de/media/nds/veroeffentlichungen/2014/07... [2] http://www.contextis.com/documents/2/Browser_Timing_Attacks.pdf http://www.contextis.com/documents/2/Browser_Timing_Attacks.... and https://www.mozilla.org/en-US/security/advisories/mfsa2013-55/ https://www.mozilla.org/en-US/security/advisories/mfsa2013-5... Read the bug to see how difficult it was for the devs to fix the issues without making the feature unusable - it took years >I'd have added "You can install links if you want a simple browser letting you read static html documents", which you would have answered with "But I can't, every website require these features now", to which I'd have answered "a. Yeah, not everyone (that's an understatement) does progressive enhancement, but ultimately b. The times they are a-changing" I'm not concerned about myself. I disable stuff like WebGL that I don't use, and I block most Javascript etc etc. My concern is for the average user who has absolutely no idea these features even exist, never mind knowing which ones they can turn off without breaking the sites they use. The general insecurity of the web affects me (and everybody else). When a site gets hacked because one of the admins was exploited by a browser vulnerability and my details get leaked that affects me.

ronjouch 11y ago
> The safety of the implementation language is far from the only concern when considering the security impact of modern browser features. [...] Those kinds of things are not solvable with a safer language (in some cases that probably makes fixing timing attacks more difficult/impossible). I'm sure there are more of these kinds of things to be found. Some of them are realistically never going to be fixed now because they are baked into the standards and the browser vendors clearly care more about animating gizmos and not breaking existing sites than leaking users browser state. Good points, didn't know about the SVG exploit having taken so long. Rust (which, as you say, is no silver bullet) is one data point showing Mozilla's commitment to security, but the variance in the time to fixing exploits is worth consideration. Today's exploit was fixed in one day, SVG took 18 months. Why? Did Moz do a good job at prioritizing based on the severity / availability of exploits in the wild, or was the long time to SVG fix just caused by technical difficulties? I don't know, maybe a mozillian involved can comment.