Mozilla Will Ship Its First Rust Component In Firefox 48 (softpedia.com)

An anonymous reader quotes a report from Softpedia: Mozilla announced today plans to ship its first ever Rust code with the production releases of Firefox. The first ever Rust components will arrive in Firefox 48, scheduled for release on August 2, 2016. After teasing Rust features last year, the Mozilla Foundation announced today that Firefox 48 would contain a new media stack component that's entirely coded in Rust. The first Firefox component to feature Rust code was not chosen at random because media components often execute malicious code when parsing multimedia files. "This makes a memory-safe programming language like Rust a compelling addition to Mozilla's tool-chest for protecting against potentially malicious media content on the Web," says Dave Herman, Director of Strategy at Mozilla Research. During tests of this Rust-based media component in Firefox's unstable builds, Mozilla says that after one billion uses they have yet to see a crash or issue in the Rust media component. Last month, Mozilla released the first versions of Servo, a minimal browser created in Rust code alone. At around the same time, Microsoft open-sourced Checked C, an extension to the C programming language that brings new features to address a series of security-related issues.

Comments

Only as safe as the sandbox

[Anonymous Coward]

Java isn't supposed to be able to get out of its sandbox without permission, yet it's the source of many vulnerabilities. Why would we trust Rust to be any safer?

Re:Only as safe as the sandbox

[mandolin]

Java isn't supposed to be able to get out of its sandbox without permission, yet it's the source of many vulnerabilities. Why would we trust Rust to be any safer?

Good question.

My guess is that running untrusted Java code in a trusted Java sandbox has a much larger attack surface than playing untrusted media in a (more or less) trusted Rust app.

The Rust code should still be an improvement, safety-wise, over the current C/C++ solution.
That does not mean the Rust solution will be perfect, and it *definitely* doesn't mean you should download and run untrusted Rust apps!

Re:Only as safe as the sandbox

[Anonymous Coward]

Rust does not derive its safety from a runtime sandbox, but from static guarantees enforced by its type system. This prevents memory errors that often lead to arbitrary code execution vulnerabilities, but it does not attempt to enforce higher-level semantic security properties, e.g. if you blindly use an untrusted string as a filename, you can still be tricked into opening /etc/passwd. Rust does not inherently protect you there, nor is it advertised as doing such.

Re:Only as safe as the sandbox

[Anonymous Coward]

Rust isn't run in a sandbox. It's like C++. It simply has some assurances that the code it compiles should be free of some classical problems that plague software development in systems languages, without it also sacrificing the close-to-bare-metal aspects of languages like C++, and with much more of the costs involved being pushed to the compilation phase than the runtime phase. That's much more than the likes of Java have tried to offer, and it's also why so many people love to bash on it: it's hard to buy into the assurances without enough time passing, and it's made by a relatively small company that's popular to bash on right now.

Re:Only as safe as the sandbox

[Cyberax]

Java bytecode confinement is fairly safe. But the security model for the sandbox was a disaster, basically full of "become root" classes because it relied on poorly thought-out "code access security". Rust's security model is much simpler - it was not designed to contain untrusted code, but to make sure that trusted code is not going to blow up.

Re:Only as safe as the sandbox

[Tough Love]

Java isn't supposed to be able to get out of its sandbox without permission, yet it's the source of many vulnerabilities. Why would we trust Rust to be any safer?

Maybe because Graydon Hoare designed it, the same guy who did Monotone, the ancestor of Git. Something about the Sun/Gosling attitude to systems design, seems like a lot of lather and little substance.

Re:Only as safe as the sandbox

[whh3]

I wish I had mod points to recommend this. Thank you for writing so succinctly about how the "safety" of Rust is not based on a runtime sandbox but rather on compile-time analysis that determines which operations are inherently unsafe and which are safe. While Rust advocates compare their safety constructs with those that Java attempts to provide, they are achieved completely differently. Thanks again for pointing this out.

Re:Only as safe as the sandbox

[serviscope_minor]

That does not mean the Rust solution will be perfect, and it *definitely* doesn't mean you should download and run untrusted Rust apps!

Yes. Rust isn't a sandbox, it's a programming language with memory safety built into the type system. A rust program can do whatever it wants to your system if you don't sandbox it yourself. On the other hand, whole nasty classes of bugs related to buffer overflows, stack smashing and data races cannot happen, which makes it harder to attack from the outside than C.

It says nothing about whether you should trust a particular rust program to not be malicious.

Re:Only as safe as the sandbox

[gweihir]

On the other hand, whole nasty classes of bugs related to buffer overflows, stack smashing and data races cannot happen, which makes it harder to attack from the outside than C.

That so only true if the compiler and run-time system do not have bugs. How well that assumption holds up in practice can be seen in other languages. And, because they are "safer", languages with safe memory usually come with less competent coders, which often nicely eliminates any advantage gained.

My prediction is that Rust will do nothing security-wise as soon as attackers actually start to attack it. Initially, it will of course seem to improve things, because attackers will not invest the time to find out how to deal with a new technology that may not even be around for a longer time.

Re:Only as safe as the sandbox

[dmpot]

Rust does not aim to provide you a sandbox to run untrusted code. Its goal is to provide type safety. It means that code written in Rust is as safe as written in Python or in another high-level language, but it runs as fast as if it were written C++.

Obviously, it could be bugs in the Rust compiler or an unsafe library that you use, but the attack surface is much smaller in this way. Take a look at programs written in high-level languages, you do not hear about buffer overflow and other low-level attacks against them very often, though they also rely on some unsafe code and may have implementation bugs.

Most attacks against applications written in high-level languages focus on the application logic. For example, attackers may try to force the application to overwrite some configuration file, which enables them a remote access, or create an executable file, which can be then run remotely, etc.

So for most practical purposes, Rust eliminates certain classes of attacks. This does not mean that applications written in Rust are truly safe, but they are likely to be much safer than written in C/C++.

Re:Only as safe as the sandbox

[garethjrowlands]

Java isn't supposed to be able to get out of its sandbox without permission, yet it's the source of many vulnerabilities. Why would we trust Rust to be any safer?

This isn't even wrong. The media component needs to be free of bugs/vulnerabilities, not execute untrusted code.

The better comparison is with C because if the media component wasn't written in Rust, it would be written in C. Memory safety is the safety-critical attribute that Rust and Java have that C lacks. This is not the same as a sandbox. Sandboxes are indeed important in browsers - Chrome and Edge/IE have them and Firefox's sandbox (Electrolysis) is under active development. Rust is a low level language comparable to C, which has an advanced type system that ensures memory safety and other important invariants. Java, by contrast, does not have an advanced type system but does have an advanced runtime system. There have been many vulnerabilities in Java's runtime and libraries, which are large and involve a significant amount of C code.

Think of Rust code as C code that's proven not have suffer certain classes of bug.

Re:Only as safe as the sandbox

[garethjrowlands]

> That so only true if the compiler and run-time system do not have bugs.

We can be certain there are no bugs in Rusts run-time system because it doesn't have one.

It's true that the compiler needs to be correct but that's true of all compilers. Rust is a clean, modern design and the critical parts of the compiler are fairly small, so the Rust compiler's chances of generating correct code are pretty good, even compared with much more mature C compilers.

Re:Only as safe as the sandbox

[dos1]

Rust doesn't do anything magical to the security of programs written in it. Rust simply won't allow you to compile quite a lot of vulnerable programs that would be happily compiled by a C compiler, because the language is a lot stricter in terms of memory and thread safety.

Also, "safety" of Rust actually requires you to be rather more than less competent. There's a rather steep learning curve, less competent coders will struggle (and learn a lot in the process) just by trying to come up with a code that will be finally accepted by the compiler. Rust doesn't provide safety by holding your hand and doing stuff for you - it's more like a strict parent that sets up boundaries of how you can play, so you won't hurt yourself, but otherwise leaves you alone.

Of course it doesn't mean that you can't write vulnerable code in Rust. It's just a bit harder to do it by accident for some class of potential issues.

Re:Only as safe as the sandbox

[serviscope_minor]

That so only true if the compiler and run-time system do not have bugs

Well the Rust runtime is provably bug free. The proof is pretty trivial: it doesn't have a runtime.

How well that assumption holds up in practice can be seen in other languages.

How many other languages out there get the safety through the type system rather than other mechanisms like sandboxing? A sandbox for a complete and growing system is a much larger attack surface than the relatively small surface of the compiler.

For the language to be insecure, there are basically 3 classes of bug:
1. There's a bug in the type system.
2. The compiler has a bug and allows invalid programs from (1) to compile.
3. It generates incorrect code in a way that's exploitable

The thing is, a C compiler is just as likely to have those bugs, especially the largest, 3, and doubly so since the Rust backend shares an optimizer with a popular C compiler.

And, because they are "safer", languages with safe memory usually come with less competent coders, which often nicely eliminates any advantage gained.

There's two things wrong with that. First you're comparing an average based on social factors to whether a specific program with a specific team will have bugs, which is a false comparison.

Secondly, Rust does not relieve you of the burden of thinking about memory (like say, Javam C#), it forces you to think very hard about it and won't compile if you think about it wrong.

My prediction is that Rust will do nothing security-wise as soon as attackers actually start to attack it.

Compared to C? I think that's unlikely because Rust is basically like C and C++ in machine model, but with several rich sources of bugs more or less removed.

Re:Only as safe as the sandbox

[lucm]

I don't know, man. I googled a picture like I always do when I come across the name of someone who's supposed to be big, and that guy looks like a dentist that had a psychotic break and turned into a serial killer. Based on that I don't trust him, or rust.

Re:Only as safe as the sandbox

[Sloppy]

And, because they are "safer", languages with safe memory usually come with less competent coders, which often nicely eliminates any advantage gained.

Ah, the nobody can make things better argument, because if you improve things, someone will (should!) use up the extra slack they're given. You're basically arguing that software needs to have a certain amount of bugs, because if it has too few, the programmer market is being inefficient by not cranking out shittier code faster/cheaper.

I don't buy it. I think it's possible for things to be better, that net gains are possible.

I cite the entirety of humanity's technological progress as my evidence. Someone said, "You can't improve on gathering! If your 'farming' idea takes off, people will just fuck up the food supply some other way, in order to stay incompetent." That person was wrong.

My prediction is that Rust will do nothing security-wise as soon as attackers actually start to attack it.

Okee dokee. I'm betting on the other side. I guess we'll revisit this in a few years, then.

Re:Only as safe as the sandbox

[mvdwege]

How many other languages out there get the safety through the type system rather than other mechanisms like sandboxing?

I know of one: Ada. And it has a well-deserved reputation for safety.

Re:Only as safe as the sandbox

[K. S. Kyosuke]

It's technically equivalent to a sandbox, but sandboxes work, which is why Rust works. Just because X can also be done badly doesn't mean that X can't be done well, too.

Re:Only as safe as the sandbox

[K. S. Kyosuke]

We can be certain there are no bugs in Rusts run-time system because it doesn't have one.

All languages these days have *some* kind of runtime system. Even if it's just a set of low-level trusted primitives. But the important thing is that it has to be small and not try to do everything.

Re:Only as safe as the sandbox

[K. S. Kyosuke]

Rust doesn't do anything magical to the security of programs written in it.

Isn't it the case that Rust allows for implementations with language-enforced isolation of code domains? Because if it is, I'd definitely say it's big for security of highly performant programs, because you should be able to run foreign code (mobile code, for example?) in the same memory space, including cross-module optimizations, with (a part of) the language spec serving as your security kernel.

Re:Only as safe as the sandbox

[K. S. Kyosuke]

Well the Rust runtime is provably bug free. The proof is pretty trivial: it doesn't have a runtime.

Judging from this, it actually *does* have a runtime, in two forms: partly in form of some routines (used by some programs), partly in form of compiler transforms/IR operations (used by *all* programs) that securely inline some sensitive tasks into the program in a way that a library can't. Just like, for example, some Lisp implementations inline low-level memory operations even into higher-level programs to speed them up without sacrificing safety. So the problem is effectively the same: a finite set of primitive operations has to be securely implemented. But that is feasible, certainly more so than telling C programers not to make a mistake whenever they're using pointers.

Re:Only as safe as the sandbox

[serviscope_minor]

I know of one: Ada. And it has a well-deserved reputation for safety.

Indeed! Typesystem based safety is much better than unsafe + sandbox.

Re:Only as safe as the sandbox

[phantomfive]

Java isn't supposed to be able to get out of its sandbox without permission, yet it's the source of many vulnerabilities. Why would we trust Rust to be any safer?

You don't know what you are talking about. Rust is built to make avoid memory leaks and buffer overflows. It does a good job at that.

Java doesn't have a problem with memory overflows, either, but you got confused between the plugin and the language. The Java language was fine, the plugin (with its sandbox) had problems.

Re:Only as safe as the sandbox

[Raenex]

On the other hand, whole nasty classes of bugs related to buffer overflows, stack smashing and data races cannot happen, which makes it harder to attack from the outside than C.

That's not true because of the unsafe escape hatch and raw pointers. It's an improvement over C/C++ by having a safe default, but you can still shoot yourself in the foot.

Re:Only as safe as the sandbox

[Tough Love]

You come across as a bit on the psycho stalker side yourself.

Re:Only as safe as the sandbox

[K. S. Kyosuke]

It depends. Features like Rust's "unsafe" or Oberon's imports of the SYSTEM module can at least be watched for (and banned in a project) since their use is blindingly obvious. The raw pointer stuff seems kind of more worrisome. I find its very presence peculiar.

Re:Only as safe as the sandbox

[K. S. Kyosuke]

That depends. For me, the runtime is the thing (whatever it is) that allows the language to do certain types of actual work on a physical machine, like communicating with the OS or hardware, or managing memory, for example, especially in relation to the required semantics of the language.

Re:Only as safe as the sandbox

[gweihir]

And here we see the cluelessness of the Rust-proponents in all is glory: Unless you do bare-metal assembly, you do have a run-time system. This does not mean an interpreter or a the like, the standard libraries already form a runtime system. And yes, Rust does have one.

Re:Only as safe as the sandbox

[gweihir]

For security and safety purposes, a runtime system is everything that was not directly coded by the programmer. Bootstrap code, function dispatch, libraries, etc. all are part of the runtime system.

But I am not surprised that the Rust-fanatics try to define the runtime system away: They actually have nothing to suggest that the Rust runtime is so massively better than others, so Rust must obviously not have a runtime.

Re:Only as safe as the sandbox

[Raenex]

The raw pointer stuff seems kind of more worrisome. I find its very presence peculiar.

Raw pointers can only be used in code labeled "unsafe".

Re:Only as safe as the sandbox

[lucm]

You come across as a bit on the psycho stalker side yourself.

Totally uncalled for. I haven't received a single restraining order in July so far, there was just this tiny incident with the 7-11 guy and the cops said it wasn't really stalking.

Re:Only as safe as the sandbox

[erapert]

Considering that C, C++, and Rust all compile to machine code I think you should say "bare-metal" not "close-to-bare-metal".

Re:Only as safe as the sandbox

[gweihir]

My guess is that all the other proofs showing Rusts superiority are of similar quality: Simple, elegant and wrong. Reality is messy, and ignoring that will not make the messiness go away.

Re:Only as safe as the sandbox

[gweihir]

You are missing one critical effect here that happens to basically all technologies: At some point they have realized their full practical potential and any more "evolution" makes them less beneficial. Examples: Flying cars, tablets as replacement for pen&paper, video-telephony, the hypeloop, electronic locks, etc. The list is really endless and the proponents of these things always display the same amount of fanaticism, faulty thinking and lack of insight into the problem being targeted.

But really, that you do not even begin to understand what I am saying is no surprise. From your SlashID you should be old enough to have seen a number of "magic" new languages, tools and coding techniques only to have them all fall flat on their faces. Some people learn from that, others stay suckers their entire life.

Re:Only as safe as the sandbox

[mvdwege]

<citation needed>

Self-proclaimed expertise does not correlate well with actual expertise, and Ada seems to be doing quite well in its domains of highly-secure and embbeded software. In fact, it's having a bit of resurgence.

Those who do vocally hate on it seem to be the kind of cowboys that run after every new fad, the sort of programmers you wouldn't trust to code the right way to implement an automatic toilet seat.

(Side note: let's see who spots the reference in that last paragraph.)

Re:Only as safe as the sandbox

[Sloppy]

you should be old enough to have seen a number of "magic" new languages, tools and coding techniques only to have them all fall flat on their faces.

Of course I've seen plenty of failures and stupid ideas! I don't see that (or your cherry-picked list) as important, though. In any human endeavor if you're around long enough, you'll see that happening. I'm sure in 4999 BC some numbnuts or con-artist had a really stupid idea about how to make farming work better. I don't care about him. Lots of people try things, and there are plenty of crackpots and real-but-nevertheless-mistaken geniuses. It doesn't mean things aren't getting better, though. I've also seen successes.

How about "higher level" languages with memory-safety and/or garbage collection? There was a time when these things were new kids on the block, too, and even looked down upon. I can get some things finished far sooner in Python than in C, because I'm not having to think about some details far below the abstraction of my problem. Had I dismissed Python out-of-hand because it didn't have pointers, I'd be worse off today.

How about tools like git? (You wouldn't believe the amount of my time as a human I sometimes spent in the 1980s merging someone's changes into a "main" version.)

You don't think these things are letting people get more stuff done, in less time? We don't call them magic, we call them technological progress.

One of the things that many programmers know would help them, even if they disagree on all the details, would be to communicate with the compiler just a little better, so that certain theoretically-automate-able things can get actually automated (e.g. generate warnings to catch certain types of bugs sooner, "automagically" parallelize some types of loops, etc). It's just a matter of time and creativity, until someone really gets this done well (e.g. so procedural programmers don't have to think like functional ones).

I don't think we have reached the full practical potential for programming languages. I'm not saying Rust is the next thing, but there will be a next thing. If we're all joking about Rust and Go and Swift in 20 years (like how we joke about Ruby now), fine! But it's reasonably likely that something will have happened in that period, making a 2036 programmer more productive than a 2016 one. It'll happen because programmers have real, and increasingly well-understood, meta-problem that repeat themselves over and over again. People are aware of it and trying all kinds of things to address them.

rust community

[Anonymous Coward]

Too bad the Rust community is so toxic. Can't call a process a slave, it has to be a "follower".

Re: rust community

[Anonymous Coward]

People at my work went through the same discussions. Wtf. We aren't talking about humans here, these are machines. Should we rename the kill command too?

Re: rust community

[Anonymous Coward]

The first politically correct programming language. I hope there are more. However, I believe it should also reference more African American history and use African nomenclature. It will be much better than that racist Perl language.

Re: rust community

[Anonymous Coward]

Got me thinking of the IDE days of master and slave drives. Oddly enough never once thought of slavery in the process of using that terminology, just automatically associated it with the technological meaning.

Re: rust community

[Laconique]

You genuinely cannot see that this language is actually not neutral either. Of course the machine doesn't care but keeping politically saturated terms puts them on life support too. I am not necessarily in favor of this move but it has merit.

Re:rust community

[NotInHere]

Nope, in fact its the opposite. Thanks to its ownership model, Rust eliminates most of the ugly access bugs that you might run into if you do multithreading. It puts the information whether something needs to be locked before being accessed, or whether its totally threadsafe into the type system, so that the compiler can verify everything is working as you intended it.

Of course, its not perfect, but rust is one of the languages you might want to start your multithreaded program in. It doesn't save you from thinking about the problems, but if you got it wrong, it won't compile. There are still bugs, but none that fall into the category C++ would describe as "undefined behaviour" (and those are many times the reasons for the most evil security bugs AND the hardest to debug).

Re:rust community

[KermodeBear]

You're kidding me, right?

Please tell me that you're joking.

If this is true, I really have zero desire to learn the language. Anything swamped by the disaster of political correctness is, quite frankly, just not worth the trouble. If I'm going to use standard computer science terminology and get whined at because the same word means something not-warm-and-fuzzy in a totally different context, then I'm out.

Re: rust community

[ctrl-alt-canc]

To have a politically correct programming language, we should also take care of replacing the "do" loop controlling statement with something less imperative, like "could you", "please compute", and so on.

Re: rust community

[Anonymous Coward]

Yes, "kill -9" should be replaced by "kill --muslim"

Re: rust community

[smallfries]

You could go the whole hog and just the British version of the language. It is far more refined.

Re:rust community

[gweihir]

It is a special class of idiots that focus on irrelevant side-issues while solving a hard technological problem. A "follower" and a "slave" are also different concepts, so they are mangling technological terminology with their Newspeak. Better stay away from these people, they are not engineers at heart.

Re:rust community

[gweihir]

Indeed. A tech-community that allows SJWs to dictate terminology to them is weak and not worth being part of in the first place. At least they signal to anybody with a clue that they are broken in the head early on.

Re:rust community

[Mokki]

If we define what untrusted code to mean random binary/library from internet that your program downloads at runtime and then executes.

Rust/C++ have no support for limiting what harm that random binary code does. It can do anything and any Rust/C++ compile time protections are moot because the downloaded binary/library is not compiled or checked against the expectations.
Java sandbox (mostly used by applets) is an attempt to allow downloading binary (compiled java classes) from external source and limiting what it can do.

Trusted code is your own source and downloaded external libraries (depending on language the external libraries might be in source or binary format) one compiles into binary.
While building trusted code the type checking of the Rust/C++/Java compilers is applied. Here Rust has the most multithread/data sharing checks.

When handling untrusted input processed by your trusted code the question becomes can it cause untrusted code execution. Java (and other languages running in virtual machines or interpreters) provides the most protections. Generally only cases where safe code is calling to existing buggy C library for the data processing (for example image handling) can it untrusted input become a problem.

Re:rust community

[NotInHere]

Java (and other languages running in virtual machines or interpreters) provides the most protections

Yes, java provides lots of protections, but those protections come with a cost, that's paid by java at runtime. Rust provides the same level of protection, but it offers it at native speed (well, not 100% the same as C++, e.g. array access is always checked, so you should use iterators, they do O(1) many checks).

Generally only cases where safe code is calling to existing buggy C library for the data processing (for example image handling) can it untrusted input become a problem.

Same goes for Rust. The difference is though that you can actually write performant image decoders in Rust, while you have a hard time with Java (its entirely possible to write them, they just wont be as performant).

Re: rust community

[dunkelfalke]

Ever heard of INTERCAL?

Re:rust community

[guruevi]

From what I understand the latest benchmarks show that Rust and Java are quite even when it comes to performance. You can't just spend CPU cycles on checks and bounds without sacrificing speed.

Re:rust community

[gweihir]

Well said.

In my experience, a better language can help competent people produce good code more easily, but it can never make incompetent people produce reasonable code in the first place. And for competent people, "better" here typically means "stands in my way less often".

Their "safe space" approach reminds me of a thing most religions do: They give you a more-or-less arbitrary set of rules, and if you just follow them to the letter, you suddenly become a "good" person. (In actual reality, that does not work, of course.) Come to think of it, this fallacy may be at the core of the design of Rust. And it would also explain the toxic community that cannot deal with any kind of criticism rationally, and is so dead set on pushing their thing as the only one true thing.

Re:rust community

[erapert]

Citation?
The programming language shootout seems to show that Rust is a cut above Java's performance.

Terrible!!

[EzInKy]

I really hate seeing Mozilla getting "rusty"!!!

Re:Terrible!!

[EzInKy]

The problem is Mozilla has become as money hungry as all the master's that they serve. When was the last time you saw an argument for keeping firefox FOSS?

Re:Terrible!!

[TangoMargarine]

Except for the part where Rust itself is the "new and shiny."

Re:Terrible!!

[TangoMargarine]

Last I heard there are also some people who still believe that Pale Moon is worth using.

It is. Are you just another person who doesn't undestand how forks work and therefore dislike them, or do you have an actual reason?

and haven't lost our ability to configure the browser so that it doesn't offend our fragile, melodramatic minds.

Except for the things that have actually been removed from even about:config. Mozilla, how far you've fallen.

Re:Terrible!!

[TangoMargarine]

It's just a fork for a few people stubbornly clinging to the past, desperately trying to paint that past as "better"

Well what do you expect, when you make it nearly impossible for them to keep their comfortable browsing experience? (I assume you're involved with Mozilla somehow.)

Maybe Pale Moon will be a serious contender if they ever get truly serious about testing, security vetting, and they pull in some more talent.

This just comes off as sour grapes. "Those bastards stole our code, but at least they'll never be successful."

Man, this is the first time I've seen something that's so clearly FUD that the term actually popped into my head unbidden.

Who but Mozilla?

[EzInKy]

Who but Mozilla can we trust to protect our privacy? Everyone else seems to want to profit in one way or another.

Re:Who but Mozilla?

[Rexdude]

Mozilla is no longer what it used to be - one that placed users first. All they've been doing is dicking around with the UI, and getting rid of all the customizability that attracted people to it in the first place(XUL and XPCOM support is going away - so many popular extensions that modify the interface and add features are going to go away), to make it a pale copy of Chrome. The only browser today that follows the charter of the original Mozilla is Pale Moon, which was forked off Firefox 24 and will continue to support XUL and proper extensions, and provide a full blown desktop UI instead of a dumbed down touchscreen/mobile friendly one.

Re:Who but Mozilla?

[Anonymous Coward]

More bullshit.
Always the trolling on Mozilla posts. IT is so old and frankly untrue.

Re:Who but Mozilla?

[Anonymous Coward]

Pale Moon is only worth it if you want to keep using obsolete tech. It's otherwise no better than Firefox, and has not improved significantly since its inception. It has already broken compatibility with more addons than Firefox did. It will either break compatibility with the obsolete tech you list in your post, or it will continue its slow downward spiral into irrelevance. It simply doesn't have the development community to be its own browser, and once Mozilla (rightly) stops supporting those outdated legacy things, you'll be SOL. Unless of course Pale Moon's community starts to actually pitch in beyond silly PR campaigns that overrate Pale Moon and poo-poo Firefox for "leaving them behind".

Re:Who but Mozilla?

[Anonymous Coward]

Pale Moon is obsolete. Already it struggles with Javascript-heavy sites like Google Maps and it has hacks to get around sites that (correctly) detect it as out of date. It's only a matter of time until it becomes unusable on the modern Web.

Re:Who but Mozilla?

[EzInKy]

As Microsoft and Ubuntu have yours?

Re:Who but Mozilla?

[thegarbz]

What bullshit? Care to provide and cite counter examples?

Re:Who but Mozilla?

[TangoMargarine]

It's otherwise no better than Firefox, and has not improved significantly since its inception.

Don't fix what ain't broke. Pale Moon has unfucked the Firefox interface, which is a big improvement in my book.

It has already broken compatibility with more addons than Firefox did.

A) They've got a whole library of fixed extension for ones that are broken.
B) Firefox is jettisoning their entire extension system anyway in the near future so it's not like they'll be any better.

or it will continue its slow downward spiral into irrelevance

Are we talking about PM or FF? Have you looked at your user figures recently?

and once Mozilla (rightly) stops supporting those outdated legacy things

You mean the things you're ripping PM for not supporting in this very same post?

It's rather interesting that all these posts are by (presumably the same) Anonymous Coward, too.

Re:Who but Mozilla?

[TangoMargarine]

Just because it still kinda works doesn't mean it ain't broke. Not wanting to accept that changes nothing. Pale Moon keeping the old UI around hasn't made it any less broken.

For somebody who's whining about my "deflector shields", you're making similar assumptions, just in the opposite direction from my opinion. Just because you like Firefox's interface doesn't mean everybody else does. Again, look at the user figures for how many people are still on Firefox.

Keeping XUL/XPCOM around all this time in Firefox did little to improve it or fix its problems, it just made it more difficult for Firefox devs to actually fix the rest of the browser.

Lumping together mangling the UI and replacing the extension system muddies the argument. You could have replaced the extension system without turning the UI into Chrome.

And how are Pale Moon's figures doing lately? If that's your supposed to be an argument for Pale Moon

I'm not the one trying to upsell PM

Nope, not even what I'm saying.

You're admitting that all the things you're complaining about Pale Moon doing, Firefox is comparably bad at, so I guess I fail to see what point you're trying to make. That we should use Chrome? If you want to use Chrome, go ahead; I would prefer Firefox not try to become Chrome, but keep being Firefox. But that ship has long since sailed.

Whether or not Firefox is also a crumbling house of cards is irrelevant to this conversation

Wow, that's sure convenient. Have you ever heard that expression about stones and glass houses?

Re:Who but Mozilla?

[TangoMargarine]

For somebody trying to argue that Pale Moon is worse than Firefox, you're doing a terrible job of it.

Re:Who but Mozilla?

[Blaskowicz]

For somebody who's whining about my "deflector shields", you're making similar assumptions, just in the opposite direction from my opinion. Just because you like Firefox's interface doesn't mean everybody else does. Again, look at the user figures for how many people are still on Firefox.

What would be the absolute number of desktop web browser users who use Firefox?
I don't know what such numbers are (total number of desktop web users, year by year) but for the sake of the argument, 30% of 500 million desktops or 14% of one billion desktops is about the same fuck ton of users.
Or take that figure of 7% market share and apply it to 1.2+ billion users.

Re:Who but Mozilla?

[TangoMargarine]

On the other hand, Mozilla has lost more users that most web browsers will ever have.

Re:Who but Mozilla?

[TangoMargarine]

For anyone interested in numbers, I threw together a rough timeline:

47.9% July 2009 3.5 - peak Firefox usage
46.4% July 2010 4
42.0% July 2011 9
        FF12 - final release to support Windows 2000 and Windows XP RTM & SP1
        FF15 - automatic silent updates
33.7% July 2012 17
        FF19 - built-in PDF viewer
        FF20 - replacement download manager
        FF21 - Social API "multiple providers"
        FF23 - no more <blink>, new logo, JavaScript permanently enabled, can't keyword-search in URL bar
28.9% July 2013 26
        FF27 - more Social API
        FF29 - Australis, no add-on bar
        FF30 - disable most plugins by default
        FF31 - first Australis ESR; previous ESR automatically updated to this version Oct 2014
24.9% July 2014 34
        FF38 - Pocket integration
21.3% July 2015 39
        FF40 - touchscreen/Australis improvements, extension signing mandatory in future
        FF45 - Tab Groups removed
16.9% May 2016

So by now the lost percentage points have probably crossed the 2/3rds point.

http://www.w3schools.com/brows...

Re:Who but Mozilla?

[Anonymous Coward]

Market share percentages means nothing when you don't include how the market changes. There has been a massive increase in mobile browser usage and Firefox doesn't do well there. Is Firefox usage actually going down or is it just not increasing as fast as other browsers? Since you left that info out, your post is effectively useless and very misleading.

Though the timeline is nicely formatted.

Re:Who but Mozilla?

[TangoMargarine]

I'm sure all the shenanigans the Mozilla team has gotten up to over the last several years had nothing to do with their user numbers. Nope. Not at all. Couldn't be.

your post is effectively useless and very misleading.

Hey, at least I tried giving any numbers at all.

Re:Who but Mozilla?

[Waccoon]

What's wrong with having Pale Moon and Firefox installed side-by-side? Yes, it's a pain, but it's what I deal with to prevent the likes of Google and friends from reading over my shoulder in ways they refuse to disclose.

I use Pale Moon as my main browser, and Firefox for development. The only extensions I need for my main browser are my ad blocker and script blocker, and I'm pretty sure those will work well with Pale Moon for many years to come. Since I don't have to restart Pale Moon every 10 minutes due to memory hogging, like I do with Firefox, I don't even need Session Manager anymore.

Hate on it all you like, but I for one am very glad that Pale Moon exists, and not everyone is willing to jump on the latest shiny (and generally untested) technology. I'll use it as long as it works for me. If Mozilla is more interested in adding yet more features to enhance my experience and force me to use social tie-ins I don't need, then I don't consider it to be more secure at all.

leaks

[nten]

I think part of Mozilla's motivation to use rust is that it prevents leaks and they know they have many.

Re:Here we go again

[secretsquirel]

Not me, I want a pony.

Re:Oh, that's just jolly

[arglebargle_xiv]

It really depends on where the rust occurs. If it's just on the panelling or in the chrome then you can sand it down and repaint, but if it's structural rust you're pretty much hosed. Time to switch to Pale Moon, which hasn't started rusting yet.

Re:Oh, that's just jolly

[ChunderDownunder]

Well if Slashdot had linked the Mozilla blog post instead of some random softpedia clickbait, you might have read where they are working with distros to incorporate the rust toolchain.

We have active discussions from the Rust side on getting the rust compiler into all of the major Linux distributions. There's definitely some complexity there, but the Rust community is working hard on doing it before Firefox would require Rust to build by default.

Re:48?

[Gavagai80]

41? It died for me at version 3.6.

Re:Oh, that's just jolly

[NotInHere]

In fact there is already a debian package of rust: https://packages.debian.org/st...

And debian means ubuntu and lots of other distros.

just because it can't happen doesn't mean it won't

[Anonymous Coward]

I think the most valuable point to make is that by abstracting buffers in a meaningful way, when hackers eventually figure out how to get past the protection mechanisms... probably by stepping through the rust compiler to find loopholes, a single patch should fix all instances of the vulnerability.

Also, it should protect against code injection attacks, but it doesn't mean it's a silver bullet. It should still be possible to cause browser crashes due to I handled memory exceptions. Consider an H.264 decoder which makes a large number of branch decisions. Intentionally malicious H.264 data can still cause crashes due to OOM because of long frame sequences that could require the decoder buffers 500 seconds of frames for prediction.

Also, even when coding in Rust, optimization will be an issue. For application code, no problems. But for decoding images and video, decisions will be made to optimize code which can be performance lethal. If buffer checks are performed every time bits are decoded from the entropy coding mechanism, it could take a LONG time to decode all the bits of a frame. So, programmers will start using C or Assembler (as they always do) to optimize this code.

Consider that modern browsers also require encoders and performance of a heavily memory checked language will kill it. Even today x264 can't handle real-time with any quality for 4K video on most CPUs and Intel's hardware encoders are extremely poorly optimized for I and P only encoding as required for conferencing.

The language is certainly not a silver bullet. It's a piece of the solution. What worries me is the crazy thought process people will have about "I'm using Rust, I don't have to think about memory anymore".

Re:just because it can't happen doesn't mean it wo

[Anonymous Coward]

The choice to use Rust for the media stack may indicate that the performance concerns you mention aren't a problem in practice, or at least that the cases where it's a problem can be nested inside an unsafe{} block without significant concern.

Most of rust's sanity checking happens at compile time, so the performance cost should be 0 in those cases. There's no runtime. It does bounds checking on arrays by default, but those are optimized out if you use iterators or if the compiler can prove that the index is never out of bounds. You can also use the previously mentioned unsafe keyword to skip bounds checking, if you're convinced that you're smarter than the compiler and the checks are causing a noticeable performance impact, though branch prediction on modern processors can alleviate much of the overhead for that.

There's no shortage of things to criticize about the language, but by all indications I've seen, speed/optimization is not on the list.

This ignores the rotting elephant in the room..

[hairyfeet]

Which is that JavaScript is toxic and MUST be replaced. You remove JavaScript from the equation? Suddenly all the nasties just disappear.

So I really don't care what language they write their video player or whatever in because until we deal with the rotting elephant carcass that is JavaScript I just don't see this change doing jack squat in the long run.

Re:This ignores the rotting elephant in the room..

[dremon]

Javascript can be used simply as a middleware language (or a 'bytecode'), and an application written in strongly-typed language can be simply compiled into it. And most likely that's what will happen.

Re:This ignores the rotting elephant in the room..

[gweihir]

While I agree that JavaScript is a horrible abomination, so much "enterprise" code these days depends on it that it will take a very long time to go away.

Re:just because it can't happen doesn't mean it wo

[garethjrowlands]

... "I'm using Rust, I don't have to think about memory anymore".

Rust is a low level language that forces you to think about memory. It's like a modern C. You can see for yourself how much of the Rust manual deals with memory management. In particular this page shows how the Rust stack and heap are the same as in C: https://doc.rust-lang.org/book... . The thing Rust has over C is a type system that eliminates common classes of bug.
 

Re:only an idiot

[lucm]

The real lesson in Star Wars is not the attack surface, it's the fact that when you know about a weak spot you don't have your squadrons of fighters and bombers start at the other end of the ennemy base to make their way under heavy fire and defense and have them mowed down as they approach the target.

Re:Erosion of meaning

[Merk42]

If it's the latter then Rust should be boycotted in an attempt to prevent stupidity from spreading.

Fight fire with fire. Join the Rust community and complain that nearly every command is "triggering". It'll have to go through so many changes to the point of making the entire language unusable.

Re:Here we go again

[secretsquirel]

:D

Re:just because it can't happen doesn't mean it wo

[serviscope_minor]

What worries me is the crazy thought process people will have about "I'm using Rust, I don't have to think about memory anymore".

I can't imagine anyone who's used rust actually saying that. If you don't think about memory hard enough, the Rust compiler will whine horribly and won't compile your program. That's one of the biggest complaints about it AFAICT!

Rust?

[QuietLagoon]

Unwanted iron oxide that is usually scraped away?

Re:Here we go again

[TheRaven64]

Not me, I want a pony.

Here you go. I'd also prefer it to Rust.

Re:Is Rust mature enough to adopt in place of C++?

[Anonymous Coward]

Start a small project and then grow larger. Do not try to put it into a critical path of your project plan.

Then I am quite sure it will work as advertised. "Rusting" an existing system is possible, but that is certainly the hardest way to get accustomed to this language.

Go for a small tools or independent processes, communicating via TCP/IP.

What you cannot do is the dirty hacks of C and C++. Rust forces common sense practices, something many people find offensive, because they have accustomed themselves with shitty stuff such as pointers into arrays, void*, insane type casts and so on.

Rust is about robust engineering and requires the fitting mindset.

So is this one

[rossdee]

version of FF that we should skip?

Re:only an idiot

[Blaskowicz]

Also when you spend $100 trillion on building some huge moving military base made with a billion tons of steel etc., you'd better defend it with 1000+ Tie fighters not 20 or so.

Re:Is Rust mature enough to adopt in place of C++?

[T.E.D.]

If you want a mature language with all the same design goals as Rust, look at Ada.

Re:only an idiot

[K. S. Kyosuke]

If only computer systems could be built from a small set of basic elements and a small set of provably-correct rules to build larger structures on top of those. ...oh wait, they can!

I would be excited about this but,

[Grand Facade]

Firefox routinely crashes on my OSx so much so I have abandoned it.

Re:I dumped Firefox, and I feel fine

[Blaskowicz]

If you had such special needs and hated the version churn why not use the medium-term support version? (ESR 31.x, 38.x, 45.x)

Re:More Precisely

[umghhh]

Magic thinking is a problem not only in SW development but in any project. In SW projects however the problem usually is that because there is no material cost you can redo things (possibly better) at no cost which of course is not true. Then there are some agile nonsense that have not much to do with the way Toyota did its first 'remove the walls' and use stickers experiment - successful projects are successful because they have luck, good crew and good leaders. How this all is arranged around is not important as long as the way fits the purpose. Doing agile for agile sake is as silly as doing water fall (or whatever other combination of words) for its sake - ideology does not work well in engineering.

Re:Oh Boy

[mandolin]

Ummm ... here's better info about why the name was chosen:
https://www.reddit.com/r/rust/...

Rust

[jez9999]

The only language whose name admits that it's out of date the day it's released.