bugmen0t

The linked paper to RAPPOR is really, really noteworthy here.

In essence, Firefox will ask itself whether it visited website X and flip a coin and if it's heads, it will lie to the server and send a random boolean. If it's tail, it will not. This way there is no way for anyone (including Mozilla) to know whether you actually visited the website. But the statistics will work out such that the collective data from everyone will give a good representation of all users. I find this a neat technology to collect data in a privacy-preserving way. And there's an opt-out (opt-in won't work because it creates bias and provides messy results).

I really, honestly don't understand why people are so upset.

An upcoming Firefox release will get built-in U2F support, no need for an add-on. It already supports a softtoken (I.e., implemented in software) behind a pref. Works well for me on e.g., GitHub. But that's unlikely ever to be enabled by default in a Firefox release.

meet worked well for me the other day on Firefox Nightly (57)

But the flexibility did not come for free! Whenever they changed internal interfaces, they'd either have to create a clone, call it interface2 or break all extensions using them. That's for internal interfaces.

The new model also means actual public support for a well-defined API. It's so much better for developers.

Besides, it also enables some big performance and security wins.

There are some noteworthy security problems with Flash in principle.

If website.com embeds a flash file from flash.example, it will run in the context of flash.example, the embedee. If website.com embeds JavaScript from js.example, the code will run in the context of website.com, the embedder.

This will and has caused problems with interoperability in so far, as I'd call it an ugly and dangerous wart.

See web security literature like "The Tangled Web" (or https://code.google.com/archive/p/browsersec/wikis/Part2.wik...) for more.

This is mostly against phishing. A phisher can get users to insert a token from a USB device or a text into evil.com. But U2F uses public key crypto, so your token derived for evil.com is not the same as for github.com

You don't really[1] need to install this, if you're using Firefox. Just set the prefs 'security.webauth.u2f' and 'security.webauth.u2f_enable_softtoken' to true.

[1] (Unless you need the token to live in your Mac OS keychain, instead of the Firefox profile directory.)

> Mozilla effectively bans extensions they don't like since the made signed extensions mandatory.

Not true. They sign very liberally and you can even host signed extensions for your own users exclusively without listing them on addons.mozilla.org at all.

yup. 30ish for a full compile, less with ccache and other tricks. Rebuilds 2-3 minutes.

The backstory here is that Thunderbird devs would like to be faster but have a hard time working against the Gecko changes that breaks their build.

Sure Thunderbird kind-of works, as in it's "done", but people find Security bugs in the Firefox base and it's not sure how they apply to Thunderbird to Thunderbird has to take the update and then they have to deal with the breakage and the incompatibility. You can't just stop and be on Firefox 45 forever. That's just asking for trouble.

Yeah, it was discussed in the W3C WebAppSec group, but there are many unsolved challenges.

This article sums it up really, really well: https://hillbrad.github.io/sri-addressable-caching/sri-addre...

Sure, there's retire.js at https://retirejs.github.io/retire.js/

websites can be made immutable:

https://hacks.mozilla.org/2017/01/using-immutable-caching-to...

I, as someone who worked on the SRI spec find this incredibly disappointing as well. We've tried to reduce this to "must be publicly cachable", but attacks have proven us wrong.

And unfortunately, there are too many hosts that make the attack you mention credibly silly:

It is not uncommon that the JavaScript served by home routers contains dynamically inserted credentials. And the JSON response from your API is valid JavaScript.

Addendum

To be completely honest: Only reach out if you have solutions for any of the problems or can reduce what you want down to something that is solvable with these problems in mind.

If your solution does not live on the web, you'll have a hard time finding allies in the standards bodies that work on the web :)

You'll have a hard time convincing spec editors and browser vendors already. The working group mailing list is https://lists.w3.org/Archives/Public/public-webappsec/

If you have minimal edits to the spec, we can take it straight to Github. SRI spec contains a link to the repo.

Folks in W3C webappsec are interested, but the cross-origin security problems are hard. We'd love feedback from developers as to what is still useful without breaking the web. Read this doc and reach out! https://hillbrad.github.io/sri-addressable-caching/sri-addre...

Two notes:

2) There is interest and progress on securing web applications: - For early research papers look into 'Privilege Separation in HTML5 Applications' by Devdatta Akhawe et al. <https://www.usenix.org/system/files/conference/usenixsecurit.... - For more practical concerns, see the stuff coming out of the W3C WebAppSec Working Group (CSP, Suborigins, etc.). - For Sandboxing/Compartmentalization of code, see the Realms proposal coming in to a future version of ECMAScript (JavaScript): <https://github.com/caridy/proposal-realms>

2) Firefox new-style extensions (WebExtensions) are in fact least-privilege.

Most wifi hardware supports being both AP and client at the same time. This way, I've extended my wifi signal for just 20 bucks (Bought a netgear ex2700 and flashed openwrt. I made it join my existing wifi and create an AP with a distinct SSID on the same interface and channel)

What you are looking for is called "remote attestation".

(In open source software the solution to this problem is "well, you could always just host your own instance" ;))

Tracking like this does not work when you use Firefox with Containers :) See https://wiki.mozilla.org/Security/Contextual_Identity_Projec...

Btw, this web page has a nice overview of what security indicators look like on different web browsers: http://lock-museum.herokuapp.com/

I'd argue this is a good reason to browse from within a virtual machine :-)

TLDR: No.

The author is missing the point of the Tor Browser. They don't try to make fingerprinting impossible. They want to make the outcome uniform across all users. See "Strategies for Defense: Randomization versus Uniformity" in their design docs [1].

And (as other said) uniformity is increased when using an anonymous/privacy enhancing operating system like Tails or WHONIX underneath.

[1] https://www.torproject.org/projects/torbrowser/design/#finge...

Mozilla allows almost every job to be remote and Firefox is written in C/C++. I'm sure there must be other companies :)

The browser must not know the content (or the hash of the content) of files on your intranet (or any other domain that is not the one you are visiting right now.)

See https://annevankesteren.nl/2015/02/same-origin-policy and http://w3c.github.io/webappsec/specs/subresourceintegrity/#c...

"On a failed integrity check, an error event is thrown. Developers wishing to provide a canonical fallback resource (e.g., a resource not served from a CDN, perhaps from a secondary, trusted, but slower source) can catch this error event and provide an appropriate handler to replace the failed resource with a different one."

Source: https://w3c.github.io/webappsec/specs/subresourceintegrity/#...

0. evil.com hosts evil.js, <script src=evil.js integrity=foo>.

1. you visit evil.com and the browser stores evil.js with the cache key "foo".

2. you visit victim.com which has an XSS vulnerability, but victim.com thinks it is safe because it uses Content Security Policy and does not allow inline scripts or scripts form evil domains.

3. the XSS attack is loading <script src=www.victim.com/evil.js hash=foo>

4. the browser detects that "foo" is a known hash key and loads the evil.js from cache. Thinking that the file is hosted on victim.com - when the file is in fact not even present.

5. the evil.js script executes in the context of victim.com, even though they use a Content Security Policy to prevent XSS from being exploitable.