Mozilla saw that there is no future in being the browser that doesn't work with Netflix, Youtube, Hulu etc. DRM sucks but shutting down Mozilla over it would have been counterproductive. Mozilla did what they could to mitigate the damage, e.g. making sure that Firefox DRM modules work with downstream Firefox distributors like the Linux distros.
Ad blocking: Mozilla has shipped Tracking Protection, supports ad blocking extensions on Android where Chrome doesn't, and is ramping up more built-in blocking features.
Not sure what you're on about with "decentralized protocols". Mozilla is working closely with the Tor people to integrate their Tor browser anti-tracking features into the core of Firefox.
Meanwhile, Mozilla successfully and almost singlehandedly blocked Google's (P)NaCl/Pepper power play. Mozilla continues to make huge investments in their own browser engine for the sake of Web standards when even Microsoft just caved in to Chromium. To the extent that Web standards other than "what Chrome does" have any meaning, Mozilla is largely responsible for that.
Meanwhile, what are you doing for the open Web, other than pouring contempt on the people who are still fighting for it?
Gene expression is fantastically complex and it is likely that experiments to increase intelligence will have nasty side effects (cf. Tay-Sachs in Ashkenazi Jews). That is why even most leading researchers in genetic modification favour a moratorium on human germline editing, at least for now. The Chinese and Russian oligarchs may have some nasty surprises.
Mozilla didn't see site isolation as a high priority until Spectre happened. Unfortunately it is now obvious that given a high-resolution timer, JS can probably read the contents of almost everything in the address space of the process it belongs to using side channels. That means site isolation has to be a priority.
As a temporary fix various timing channels have had their precision reduced, but that's only a partial workaround at best. Also Mozilla wants to enable parallelism primitives for Javascript that can be (mis)used to gather high-precision timing data.
Fine-grained multiprocess has some downsides but Mozilla can't afford to lag behind in security and privacy.
If you want the host to not know content is being blocked, the browser needs to download all blocked content, in which case you're giving up one of the main performance advantages of content blocking.
If Chromium becomes the only browser engine then you won't have to worry about "W3C standards", because whatever Chromium does (bugs and all) will *be* the standard and the W3C might as well cease to exist. That is one of the problems with monocultures.
Digital transactions will increase (though in a lot of countries most transactions are already digital), but they don't require the use of digital currency. When digital currency does get used, it mostly won't be Bitcoin, since proof of work is incredibly inefficient and only of value to the tiny minority who care to eschew fiat currency.
Buying Bitcoin because something else inspired by Bitcoin might become valuable is crazy.
> Legacy programs would need to be ported wholesale to take advantage of these languages,
Not true for Rust. C libraries and applications can be ported to Rust incrementally and, in fact, some examples have already been done and shipped! See Federico's work on librsvg for example: https://people.gnome.org/~fede...
De Raadt is wrong about this. Today, on Linux, Firefox content processes run in an extremely confined sandbox. For example they have no access to any file system or network resources. It sounds like they've had trouble porting Firefox's sandboxing approach to use OpenBSD pledge() sandboxing, but that is probably more about the limitations of pledge() than Firefox's sandboxing approach.
Then he says "I think firefox is still only 2 process classes" but I can think of at least 4.
Chromium is ahead of Firefox in some areas, namely fine-grained "process per site" isolation, but Mozilla is focusing a lot of energy on catching up there.
You're flat-out wrong about this. CSS Variable Fonts is *not* about packaging multiple typefaces in the same file. There is a single typeface in the file, with one or more continuously variable "axes" (e.g. "weight" or "width", but you can define other axes like "serif-ness") to control the shape of the glyphs. You should have read the page you linked to.
Horizontally stretching glyphs to justify lines sounds like a good feature but it would have to be a CSS feature in its own right, because the browser would have to apply different stretching per line.
AV vendors inject DLLs into browser processes and monkeypatch browser machine code in crazy ways to monitor browser activity. Predictably, this has created all kinds of problems. It's common for browser updates to invalidate some assumption made by the AV developers, causing frequent browser crashes. It's also common for the AV hooks to have terrible performance properties. It's also common for the AV code to introduce security vulnerabilities.
AV vendors know that when the browser crashes or is slow, users will inevitably blame the browser, not the AV vendor, because the AV software is not visible when the problem occurs. Thus, they have few incentives to fix their issues.
A few concrete examples from Firefox: * For a long time an AV vendor injected ASLR-disabled DLLs into Firefox, making browser exploits much easier. * An AV application parsed Firefox DLLs to find the right places to apply patches. Their PE-format DLL parser had bugs; a small and completely legal change to a Firefox DLL triggered a parser bug, causing the AV patch to be applied at the wrong place, i.e. randomly corrupting Firefox code. * An AV application patched Firefox code, obtained a pointer to a Firefox object, and started using it on another thread. That object was only safe to use on the main thread. Result: random crashes.
Of course people argue that all AV vendors shouldn't be tarred with the same brush. But no-one agrees on who that mythical "good" AV vendor is.
Putting the entire browser into a single sandbox is possible but "the damage it can do if it goes rogue is sharply limited" isn't true. A compromised whole-brower-in-a-sandbox can listen to your microphone, watch your webcam, manipulate your online banking, access all your Web passwords, manipulate your Webmail, etc. It (maybe) can't mess with your other desktop applications but for many users that's of very little value.
Browsers are using those OS-level sandboxing tools to sandbox individual "content" subprocesses. A malicious site might exploit a bug to take over a content process, but those processes have very low rights compared to the main browser process. They typically can't access the filesystem at all, they can't directly access microphones and webcams (only indirectly, triggering browser UI to notify the user), etc.
Currently in Firefox code from different Web sites can share the same content process, which means a site compromising a content process can usually access content from other Web sites like online banking. This article is about improving Firefox so that is no longer the case.
A lot of people say "why haven't browsers just turned off autoplay" as if "autoplay" is a browser feature you can just turn off without affecting anything else. Unfortunately, it is not.
As a matter of fact there is an HTML5 "autoplay" feature, but it's hardly ever used. The "autoplaying" audio and video you experience is mostly scripts loading a video and calling "play()". Unfortunately, in the browser, there's no straightforward way to distinguish that from legitimate uses, e.g. a game playing a sound triggered by some event. It's even more difficult for non-audio cases, because Web developers can *and do* create "autoplaying" videos even without using script, e.g. using animated GIFs or sequences of PNG images selected by CSS. Those are much worse for users in every way than letting the site play video in a proper format.
So, browsers mostly aren't trying to block autoplaying silent video, and have to come up with heuristics to block autoplaying audio. There are tradeoffs because false positives are bad; e.g. making it hard for games to play sounds is a problem. It's easy for autoplay detection heuristics to break legitimate Web sites and cause users --- maybe not you, but other users --- to get upset, and Web developers too.
In short, this is a very hard problem, there are no perfect solutions, and the solutions being deployed now are the result of a lot of work over quite a long period of time.
It's not that simple. It's essentially trying to draw a rectangle of negative width and height. Yes it should work the same across browsers, no this is not "simply coloring a DIV tag".
Slashdot Mirror
Mozilla saw that there is no future in being the browser that doesn't work with Netflix, Youtube, Hulu etc. DRM sucks but shutting down Mozilla over it would have been counterproductive. Mozilla did what they could to mitigate the damage, e.g. making sure that Firefox DRM modules work with downstream Firefox distributors like the Linux distros.
Ad blocking: Mozilla has shipped Tracking Protection, supports ad blocking extensions on Android where Chrome doesn't, and is ramping up more built-in blocking features.
Not sure what you're on about with "decentralized protocols". Mozilla is working closely with the Tor people to integrate their Tor browser anti-tracking features into the core of Firefox.
Meanwhile, Mozilla successfully and almost singlehandedly blocked Google's (P)NaCl/Pepper power play. Mozilla continues to make huge investments in their own browser engine for the sake of Web standards when even Microsoft just caved in to Chromium. To the extent that Web standards other than "what Chrome does" have any meaning, Mozilla is largely responsible for that.
Meanwhile, what are you doing for the open Web, other than pouring contempt on the people who are still fighting for it?
This is just a wild conspiracy fantasy.
Gene expression is fantastically complex and it is likely that experiments to increase intelligence will have nasty side effects (cf. Tay-Sachs in Ashkenazi Jews). That is why even most leading researchers in genetic modification favour a moratorium on human germline editing, at least for now. The Chinese and Russian oligarchs may have some nasty surprises.
Phrenology.
Google absolutely does care about the control over the Web that Chrome brings.
Firefox does throttle CPU in background tabs. For a very long time APIs like setTimeout have been throttled aggressively.
There has been quite recent work on using OS APIs to reduce the priority of processes running background tabs: https://bugzilla.mozilla.org/s...
Mozilla didn't see site isolation as a high priority until Spectre happened. Unfortunately it is now obvious that given a high-resolution timer, JS can probably read the contents of almost everything in the address space of the process it belongs to using side channels. That means site isolation has to be a priority.
As a temporary fix various timing channels have had their precision reduced, but that's only a partial workaround at best. Also Mozilla wants to enable parallelism primitives for Javascript that can be (mis)used to gather high-precision timing data.
Fine-grained multiprocess has some downsides but Mozilla can't afford to lag behind in security and privacy.
Translation: "After a year of open discussion we didn't notice until now,"
Here for example is an overview of memory usage reductions related to Fission, from July 2018: https://mail.mozilla.org/piper...
If you want the host to not know content is being blocked, the browser needs to download all blocked content, in which case you're giving up one of the main performance advantages of content blocking.
Walk what walk?
Mozilla's position isn't that all ads are evil and should be banned. It is that ad tech should preserve your privacy.
If Chromium becomes the only browser engine then you won't have to worry about "W3C standards", because whatever Chromium does (bugs and all) will *be* the standard and the W3C might as well cease to exist. That is one of the problems with monocultures.
We agree.
Digital transactions will increase (though in a lot of countries most transactions are already digital), but they don't require the use of digital currency. When digital currency does get used, it mostly won't be Bitcoin, since proof of work is incredibly inefficient and only of value to the tiny minority who care to eschew fiat currency.
Buying Bitcoin because something else inspired by Bitcoin might become valuable is crazy.
Transactions have already mostly moved from cash and paper to electronic. Bitcoin was not and is not needed for that.
Bitcoin's distinguishing feature is to replace "fiat" with "proof of work", and that necessarily entails a vast increase in energy consumption.
Pretty major error right in the introduction:
> Legacy programs would need to be ported wholesale to take advantage of these languages,
Not true for Rust. C libraries and applications can be ported to Rust incrementally and, in fact, some examples have already been done and shipped! See Federico's work on librsvg for example: https://people.gnome.org/~fede...
De Raadt is wrong about this. Today, on Linux, Firefox content processes run in an extremely confined sandbox. For example they have no access to any file system or network resources. It sounds like they've had trouble porting Firefox's sandboxing approach to use OpenBSD pledge() sandboxing, but that is probably more about the limitations of pledge() than Firefox's sandboxing approach.
Then he says "I think firefox is still only 2 process classes" but I can think of at least 4.
Chromium is ahead of Firefox in some areas, namely fine-grained "process per site" isolation, but Mozilla is focusing a lot of energy on catching up there.
Chrome and Safari already support Variable Fonts.
You're flat-out wrong about this. CSS Variable Fonts is *not* about packaging multiple typefaces in the same file. There is a single typeface in the file, with one or more continuously variable "axes" (e.g. "weight" or "width", but you can define other axes like "serif-ness") to control the shape of the glyphs. You should have read the page you linked to.
Horizontally stretching glyphs to justify lines sounds like a good feature but it would have to be a CSS feature in its own right, because the browser would have to apply different stretching per line.
AV vendors inject DLLs into browser processes and monkeypatch browser machine code in crazy ways to monitor browser activity. Predictably, this has created all kinds of problems. It's common for browser updates to invalidate some assumption made by the AV developers, causing frequent browser crashes. It's also common for the AV hooks to have terrible performance properties. It's also common for the AV code to introduce security vulnerabilities.
AV vendors know that when the browser crashes or is slow, users will inevitably blame the browser, not the AV vendor, because the AV software is not visible when the problem occurs. Thus, they have few incentives to fix their issues.
A few concrete examples from Firefox:
* For a long time an AV vendor injected ASLR-disabled DLLs into Firefox, making browser exploits much easier.
* An AV application parsed Firefox DLLs to find the right places to apply patches. Their PE-format DLL parser had bugs; a small and completely legal change to a Firefox DLL triggered a parser bug, causing the AV patch to be applied at the wrong place, i.e. randomly corrupting Firefox code.
* An AV application patched Firefox code, obtained a pointer to a Firefox object, and started using it on another thread. That object was only safe to use on the main thread. Result: random crashes.
Of course people argue that all AV vendors shouldn't be tarred with the same brush. But no-one agrees on who that mythical "good" AV vendor is.
Non-TLS HTTP traffic can be redirected to carry out DDoS attacks and for other nefarious purposes. See https://en.wikipedia.org/wiki/....
Unfortunately the idea that there are public Web sites that "don't need" to use TLS is naive and obsolete.
Browser ARE using OS-level sandboxing internally.
Putting the entire browser into a single sandbox is possible but "the damage it can do if it goes rogue is sharply limited" isn't true. A compromised whole-brower-in-a-sandbox can listen to your microphone, watch your webcam, manipulate your online banking, access all your Web passwords, manipulate your Webmail, etc. It (maybe) can't mess with your other desktop applications but for many users that's of very little value.
Browsers are using those OS-level sandboxing tools to sandbox individual "content" subprocesses. A malicious site might exploit a bug to take over a content process, but those processes have very low rights compared to the main browser process. They typically can't access the filesystem at all, they can't directly access microphones and webcams (only indirectly, triggering browser UI to notify the user), etc.
Currently in Firefox code from different Web sites can share the same content process, which means a site compromising a content process can usually access content from other Web sites like online banking. This article is about improving Firefox so that is no longer the case.
Staunch anti-Javascript advocates are welcome to run NoScript, block all scripts, and not play any Web games.
A lot of people say "why haven't browsers just turned off autoplay" as if "autoplay" is a browser feature you can just turn off without affecting anything else. Unfortunately, it is not.
As a matter of fact there is an HTML5 "autoplay" feature, but it's hardly ever used. The "autoplaying" audio and video you experience is mostly scripts loading a video and calling "play()". Unfortunately, in the browser, there's no straightforward way to distinguish that from legitimate uses, e.g. a game playing a sound triggered by some event. It's even more difficult for non-audio cases, because Web developers can *and do* create "autoplaying" videos even without using script, e.g. using animated GIFs or sequences of PNG images selected by CSS. Those are much worse for users in every way than letting the site play video in a proper format.
So, browsers mostly aren't trying to block autoplaying silent video, and have to come up with heuristics to block autoplaying audio. There are tradeoffs because false positives are bad; e.g. making it hard for games to play sounds is a problem. It's easy for autoplay detection heuristics to break legitimate Web sites and cause users --- maybe not you, but other users --- to get upset, and Web developers too.
In short, this is a very hard problem, there are no perfect solutions, and the solutions being deployed now are the result of a lot of work over quite a long period of time.
It's not that simple. It's essentially trying to draw a rectangle of negative width and height. Yes it should work the same across browsers, no this is not "simply coloring a DIV tag".
You don't abide by any code of conduct to *use* Rust. If you want to participate in certain Rust-related forums, then they have a code of conduct.
C++ is no different in this regard. CppCon for example has a code of conduct: https://cppcon.org/codeofcondu...