Francois Marier

> Leanplum, location, "device id"

Doesn't have access to location and the unique id is specific to leanplum so it can't be tied to anything else. See [1] for an explanation (the source seems to match from my quick look)

> GCM

Firefox has certain real-time features (like sending tabs) that wouldn't be feasible without cloud messaging. Telegram FOSS and many other apps use workarounds that are less reliable, worse UX and drain battery anywhere from a bit more to HOLY SHIT WHERE DID THOSE 4500mAh GO? (source: Telegram FOSS on my OP3T) If you want to propose a better solution, I'm sure the 3 remaining devs at Mozilla would love to hear it.

> Okay, now it's time to refine this in context of "Firefox Klar", "Firefox Focus" or say, the Fenix codebase(s). ...

Sure, let's talk about Fenix - what is now available in G Play as the standard "Firefox for Android". I don't use Klar or Focus, but they use much of the same code, so all of this is quite general.

> - Mozilla implemented their own ads distribution system that hijacks google ads on pages and replaces the id with the one that was specifically generated for the web browser

The link you provided doesn't make that clear and neither do you. What "id" are you referring to? What is its significance and where in the code is it replaced?

> - Mozilla's Safebrowsing uses a generated hash, that is used specifically to identify a single device

The link you give makes no sense. The URL at the marked line is the URL from which hashes…

That's the exact point, though, Google does not get your browsing data.

What Firefox does, is that it downloads a complete list of hashes from Google's Safebrowsing server. Every instance of Firefox does this every 30 minutes. Nothing identifying about this.

Firefox then stores only the first 32 bits of those hashes to save on space (as the list is unsurprisingly gigantic). Then Firefox does a lookup against this locally stored list whenever it loads a webpage. If a webpage's first 32 bits should be on that list, then it obviously has to check if it's actually the complete hash that matches. But for that, it requests all hashes with same first 32 bits from Mozilla's server. They proxy the list for that purpose.

So, it's at best Mozilla which can guess that you browsed to one of the many pages that share the first 32 bits of the hash. Google will have no clue about it.

And in fact, they even throw in a few noise entries when requesting the full hashes from their server, so even Mozilla actually doesn't know for sure which first 32 bits you browsed to.

https://feeding.cloud.geek.nz/posts/how-safe-browsing-works-in-firefox/

The #1 missing feature in github for our team is that we can't attach files directly from Issues Web UI. Usually we need this for screenshots, but sometimes data files, logs and other artifacts. Workarounds are aplenty but all painful and problematic. See https://github.com/thisduck/gh-attachment or http://feeding.cloud.geek.nz/2012/06/attaching-files-to-github-issues.html not to mention countless internal homegrown hacks that exist out there.

This lack of attachments makes it a lot harder for non-techies to use Issues (e.g., for casual or QA testing).
Don't get me wrong, I absolutely LOVE the minimalist approach of Issues, and it is definitely _almost_ good enough feature set, but this one missing feature makes it difficult for one to imagine the use of issues at-large in broad organizations--an undiscovered area of growth for github.

I would definitely add this to the "I <heart> github, but..." list.

P.S., experiment0, great execution of a "feature request".

For anyone who's wondering, Firefox handles Safe Browsing a lot differently. There's an overview here: https://feeding.cloud.geek.nz/posts/how-safe-browsing-works-in-firefox/ It's possible that this is outdated though.

The tl;dr is that

1. Firefox downloads a list of partial hashes every 30 minutes from Google. It's only the first 32 bits of each hash. This can easily be turned off in about:preferences.

2. When you visit a website, Firefox checks the beginning of the URL against the partial hashes stored locally.

3. If the partial hash matches the beginning of the URL, Firefox downloads a list of all of the hashes beginning with the partial hash it matched.

4. Firefox checks the full hash of the URL against the new list of full hashes. If it matches, the site is blocked. If not, you continue on browsing.

When I first found out how it worked a while ago, I was pretty amazed. It goes to great lengths to not know what sites you're visiting.

For all the pains it introduces because everything Just Stops Working™, I find the i3 window manager to be fantastic for my windowing workflow.

Once you have decided what goes into each workspace and have a bit of muscle memory for the tiling, switching is instant and organizing is trivial. Never drag a window again!

These blog posts helped a lot in configuring some basic stuff (that IMO really should be available out of the box; I get that i3 is supposed to be light and customizable but it feels really user-hostile on a new install):

https://feeding.cloud.geek.nz/posts/creating-a-modern-tiling-desktop-environment-using-i3/

https://cravencode.com/post/essentials/enable-tap-to-click-in-i3wm/

You should read the Privacy section at https://feeding.cloud.geek.nz/posts/how-safe-browsing-works-in-firefox/

> One of the most persistent misunderstandings about Safe Browsing is the idea that the browser needs to send all visited URLs to Google in order to verify whether or not they are safe.

> While this was an option in version 1 of the Safe Browsing protocol (as disclosed in their privacy policy at the time), support for this "enhanced mode" was removed in Firefox 3 and the version 1 server was decommissioned in late 2011 in favor of version 2 of the Safe Browsing API which doesn't offer this type of real-time lookup.

Firefox 3 - That was 9 years ago.