mccr8

There's also Knightscope, which appears to be based in MV.

http://knightscope.com/

As Deregibus explains elsewhere, this is almost certainly using the same hash collision.

https://news.ycombinator.com/item?id=13728116

For what it is worth, Firefox also has a security bounty program, one that is older than Chrome itself. :) Of course, the payouts are smaller than those from Pwn2Own, but on the other hand, reporters don't have to demonstrate a full exploit that can actually execute arbitrary code.

We have extensive leak checking in our testing for Firefox, so hopefully the JS engine is not "very leaky".

One part of Quantum, which does not have anything to do with Rust, is to figure out how we can spend less time running unimportant JS (like maybe in a background tab), which will hopefully reduce CPU usage.

JS engines spend a lot of their time in JITted code, which isn't helped by PGO compilation of C++. (I mean, the JIT itself is of course a kind of PGO compilation...) I believe in Firefox PGO is, or at least used to, be disabled because it didn't help much, but would occasionally cause crashes due to compiler bugs.

Writing a parallel GC surely is not "low-hanging fruit" by any reasonable measure. Java already has to deal with concurrency in their objects, and throughput is more of a concern for server-like workloads, so they are dealing with a different situation. In Firefox, most of our effort has focused on improving responsiveness and eliminating work (through things like compartmental GC). (Some GC sweeping is already done in parallel in Firefox.)

That said, I believe IE does some concurrent marking, so there is certainly room for improvement.

If you go to about:telemetry in Firefox, you can see exactly what data is being collected.

Flash is not entirely dead yet, so support can't be completely dropped. However, both Chrome [1] and Firefox [2] have announced long-term schedules for removing support for Flash, bit by bit.

As for PDF, the PDF viewers shipped in browsers seem to be much more hardened against attack than the stand alone ones people use, so as a practical matter, including a PDF viewer helps keep users safe.

[1] https://chrome.googleblog.com/2016/08/flash-and-chrome.html

[2] https://blog.mozilla.org/futurereleases/2016/07/20/reducing-...

Background tabs already have their timers run less frequently. In Firefox, that was added in 2011 [1]. Certainly further improvements to reduce background tab activity would be nice. One way you can sort of get that effect is to use Reader Mode, on pages where that works.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=633421

The main reason tabs aren't saved to disk isn't a concern about responsiveness, it is a concern about data loss. You have to be very sure that you restore the state exactly. What if you spent a few hours filling out some government form online, then you went and took a break by watching a few YouTube videos? Memory usage might spike up, and the browser decides to unload the tab with the form. You'd be mad if form state got lost when you switched back.

I've heard that some people set Firefox to not autorestore tabs on load, and then periodically close and reopen Firefox, so their background tabs aren't loaded. Pretty clumsy, but I guess it gets the job done. I don't know if there's any addons that do something similar.

"Performance" in the context of e10s means improving user responsiveness rather than throughput. For instance, you can usually smoothly scroll a page or interact with the browser UI even if the page is some kind of heavyweight mess.

Currently e10s is only using two processes, so there should not be a massive increase in memory. Particularly, if you have many tabs open, the pages are still all just stored in a single process, so there should not be much overhead. Part of the work towards having multiple content processes will be ensuring the memory overhead is not too high.

Chrome sends things you type in the URL bar to Google to do prediction:

https://support.google.com/chrome/answer/95656?hl=en

From that page it sounds like it is on by default.

e10s will bring some security and stability benefits. If one webpage crashes, all webpages crash, but you can click to reload. Additionally, this enables sandboxing, so that code from webpages can be run with lower levels of access. Sure, it is not perfect, but it is a large improvement from the status quo.

(Even process-per-tab is not perfect for security: a compromised page from one origin could open an iframe to another origin.)

An experimental investigation into a multithreaded model (for UI and webpages) was investigated a few years ago (see https://bugzilla.mozilla.org/show_bug.cgi?id=718121 ), and I don't think it looked to be "much simpler". The major problem with moving to multiple processes is that JS running the UI has to be adapted to dealing with page JS that is "somewhere else". Because the JS execution model is based on a single thread, I don't think it would be so much easier to deal with JS on another thread than in another process. Requiring multiple JS runtimes would likely also increase memory usage even in a multithreaded model, though it does seem like it would be less than e10s.

Of course, now a site could potentially fingerprint you by the set of APIs you have disabled!

From that article: "We expect to significantly reduce the number of prefixed properties supported over time but Web compatibility will require us to keep around prefixed versions of some features."

The features WebKit needs to keep around to continue to work with many websites are presumably about the same as those Firefox felt it had to implement to work with many websites.

(Disclaimer: I work on Firefox.)

"Quietly" should really get added to a list of semi-clickbaity words that get excised from Hacker News titles.

https://www.google.com/?gws_rd=ssl#q=site:news.ycombinator.c...

A Quora answer to this question linked to this Google Chrome commit: https://bugs.chromium.org/p/chromium/issues/detail?id=71832

In short, it says that the prefix set uses less memory than a bloom filter.

This is a pretty common use case for Flash. There's a clipboard API of some sort now: http://caniuse.com/#feat=clipboard

That quote is talking about (untrusted) compilers that translate from C/C++ with undefined behavior to WebAssembly programs. The latter would still have a defined behavior.

People already "hammer on the entire JavaScript API with invalid parameters". That's what fuzzing is, and yes, it does find implementation errors which can lead to security problems.

Developer Edition is different than Nightly. They both do update about once a day, but far fewer changes land on Developer Edition so it should be more stable.

Firefox is changing this because malware injects itself into Firefox using this mechanism. Power users who really want to install unsigned addons can switch to the Developer Edition.

If it is just the Pocket toolbar button you are concerned about (I realize other people don't want the code in their browser at all), then you can easily remove it by using the Customize settings option.

All browsers have vulnerabilities.

Browsers are likely the only place people are using v8 to run arbitrary hostile code.

We spend plenty of effort is spent on both stability and performance. "Improved performance by x% in this particular situation that you may or may experience!" just isn't something you can wrap up neatly into a high-level blog post like you can with a new feature, so you may not get an accurate picture of where development effort is going based just on reading the official blog and release notes.

For instance, somebody just landed a pretty tricky bit of code to fix a severe incremental GC performance fault he'd been experiencing with a lot of tabs open (disclaimer: I reviewed the patch): https://bugzilla.mozilla.org/show_bug.cgi?id=1214961

This probably doesn't affect the author and commit stats for mozilla-central all that much. The various upstream libraries we use are updated infrequently, in single commits.

You used to be able to do that, but it was fixed in 2010: https://blog.mozilla.org/security/2010/03/31/plugging-the-cs...

As esailija posted elsewhere in this thread, at least one study has shown that gender differences in mental rotation tasks can be eliminated through training.