It is possible to do it, just not easy. It would be nice if mozilla addressed this, but in the scheme of severe privacy violations it’s pretty low IMO. Bookmarks, cookies, history, passwords are already exposed in the web ui which serves almost everybody except the most paranoid.
Have you seen how many open bugs firefox has? Like all open source projects, if this bugs you enough you can of course submit a patch, or pay somebody else to. I’m super delighted to contribute a few $$ to Mozilla and further their open web, as opposed to the nice but walled gardens of Apple, Google, and Microsoft. I don’t see them as being evil (eval?) nor being motivated by greed.
I find it a little ironic that after using the open-web browser that I am not able to inspect the sessionstore-backups/recovery.jsonlz4 file after a crash to recover some textfield data, as Mozilla Firefox is using a non-standard compression format, which cannot be examined with lzcat nor even with lz4cat from ports.
The bug report about this lack of open formats has been filed 3 years ago, and suggests lz4 has actually been standardised long ago, yet this is still unfixed in Mozilla.
Sad state of affairs, TBH. The whole choice of a non-standard format for user’s data is troubling; the lack of progress on this bug, after several years, no less, is even more so.
https://bugzilla.mozilla.org/show_bug.cgi?id=1209390#c10 states that when Mozilla adopted using LZ4 compression there wasn’t a standard to begin with. Yeah, no one has migrated the format to the standard variant, which sucks, but it isn’t like they went out of their way in order to hide things from the user.
It was probably unwise for Mozilla to shift to using that compression algorithm when it wasn’t fully baked, though I trust that the benefits outweighed the risks back then.
This will sound disappointing to you, but your case is as edge-caseish as it gets.
It’s hard to prioritize those things over things that affect more users. Note that other browser makers have security teams larger than all of Mozilla’s staff. Mozilla has to make those hard decisions.
These jsonlz4 data structure are meant to be internal (but your still welcome to use the open source implementation within Firefox to mess with it).
I got downvoted twice for “incorrect” though I tried my best to be neutral and objective. Please let me know, what I should change to make these statements more correct and why. I’m happy to have this conversation.
Mozilla obviously has more than enough money that they could pay devs to fix this — just sell Mozilla’s investment in the CliqZ GmbH and there would be enough to do so.
But no, Mozilla sets its priorities as limiting what users can do, adding more analytics and tracking, and more cross promotions.
Third party cookie isolation still isn’t fully done, while at the same time money is spent on adding more analytics to AMO, on CliqZ, on the Mr Robot addon, and even on Pocket. Which still isn’t ooen source.
Mozilla has betrayed every single value of its manifesto, and has set priorities opposite of what it once stood for.
Wow, that escalated quickly :)
It sounds to me that you’re already arguing in bad faith, but I think I’ll be able to respond to each of your points individually in a meaningful and polite way. Maybe we can uplift this conversation a tiny bit?
However, I’ll do this with my Mozilla hat off, as this is purely based on public information and I don’t work on Cliqz or Pocket or any of those things you mention. Here we go:
Cliqz: Mozilla wants a web with more than just a few centralized search engines. For those silos to end, decentralization and experimentation is required. Cliqz attempts to do that
You can isolate cookies easily. EIther based on custom labels (“Multi Account Containers”) or based on the first party domain (i.e., the website in the URL bar). The former is in the settings, the latter is behind a pref (first party isolate). For your convenience, there’s also an add-on for first party isolation
Cross Promotions: The web economy is based on horrible ads that are annoying and tracking users. To show that ads can be profitable without being tracking or annoying, Mozilla shows sponsored content (opt-out btw) by computing the recommendations locally on your own device
As someone who also got into 1-3 arguments against firefox I guess you’ll always have to deal with criticism that is nit picking, because you’ve written “OSS, privacy respecting, open web” on your chest. Still it is obvious you won’t implement an lz4 file upgrade mechanism (oh boy is that funny when it’s only some tiny app and it’s sqlite tables). Because there are much more important things than two users not being able to use their default tools to inspect the internals of firefox.
Sure, but it’s obvious that somehow Mozilla has enough money to buy shares in one of the largest Advertisement and Tracking companies’ subsidiaries (Burda, the company most known for shitty ads and its Tabloids, owns CliqZ), where Burda retains majority control.
And yet, there’s not enough left to actually fix the rest.
And no, I’m not talking about Telemetry — I’m talking about the fact that about:addons and addons.mozilla.org use proprietary analytics from Google, and send all page interactions to Google. If I wanted Google to know what I do, I’d use Chrome.
Yet somehow Mozilla also had enough money to convert all its tracking from the old, self-hosted Piwik instance to this.
None of your arguments fix the problem that Mozilla somehow sees it as higher priority to track its users and invest in tracking companies than to fix its bugs or promote open standards. None of your arguments even address that.
about:addons code using Google analytics has been fixed and is now using telemetry APIs, adhering to the global control toggle. Will update with the link, when I’m not on a phone.
Either way, Google Analytics uses a mozilla-customized privacy policy that prevents Google from using the data.
If your tinfoil hat is still unimpressed, you’ll have to block those addresses via /etc/hosts (no offense.. I do too).
I won’t comment on the rest of your comment, but this is really a pretty tiny issue. If you really want to read your sessionstore as a JSON file, it’s as easy as git clone https://github.com/Thrilleratplay/node-jsonlz4-decompress && cd node-jsonlz4-decompress && npm install && node index.js /path/to/your/sessionstore.jsonlz4. (that package isn’t in the NPM repos for some reason, even though the readme claims it is, but looking at the source code it seems pretty legit)
Sure, this isn’t perfect, but dude, it’s just an internal datastructure which uses a format which is slightly non-standard, but which still has open-source tools to easily read it - and looking at the source code, the format is only slightly different from regular lz4.
It is possible to do it, just not easy. It would be nice if mozilla addressed this, but in the scheme of severe privacy violations it’s pretty low IMO. Bookmarks, cookies, history, passwords are already exposed in the web ui which serves almost everybody except the most paranoid.
I’ve not used https://github.com/Thrilleratplay/node-jsonlz4-decompress but have used https://github.com/twolfson/firefox-bookmarks to export 20 years (yes, 20 years) worth of firefox bookmarks into CouchDB for a better search and sync experience.
Have you seen how many open bugs firefox has? Like all open source projects, if this bugs you enough you can of course submit a patch, or pay somebody else to. I’m super delighted to contribute a few $$ to Mozilla and further their open web, as opposed to the nice but walled gardens of Apple, Google, and Microsoft. I don’t see them as being evil (eval?) nor being motivated by greed.
I find it a little ironic that after using the open-web browser that I am not able to inspect the
sessionstore-backups/recovery.jsonlz4file after a crash to recover some textfield data, as Mozilla Firefox is using a non-standard compression format, which cannot be examined withlzcatnor even withlz4catfrom ports.The bug report about this lack of open formats has been filed 3 years ago, and suggests lz4 has actually been standardised long ago, yet this is still unfixed in Mozilla.
Sad state of affairs, TBH. The whole choice of a non-standard format for user’s data is troubling; the lack of progress on this bug, after several years, no less, is even more so.
https://bugzilla.mozilla.org/show_bug.cgi?id=1209390#c10 states that when Mozilla adopted using LZ4 compression there wasn’t a standard to begin with. Yeah, no one has migrated the format to the standard variant, which sucks, but it isn’t like they went out of their way in order to hide things from the user.
It was probably unwise for Mozilla to shift to using that compression algorithm when it wasn’t fully baked, though I trust that the benefits outweighed the risks back then.
This will sound disappointing to you, but your case is as edge-caseish as it gets.
It’s hard to prioritize those things over things that affect more users. Note that other browser makers have security teams larger than all of Mozilla’s staff. Mozilla has to make those hard decisions.
These jsonlz4 data structure are meant to be internal (but your still welcome to use the open source implementation within Firefox to mess with it).
I got downvoted twice for “incorrect” though I tried my best to be neutral and objective. Please let me know, what I should change to make these statements more correct and why. I’m happy to have this conversation.
Priorities can be criticized.
Mozilla obviously has more than enough money that they could pay devs to fix this — just sell Mozilla’s investment in the CliqZ GmbH and there would be enough to do so.
But no, Mozilla sets its priorities as limiting what users can do, adding more analytics and tracking, and more cross promotions.
Third party cookie isolation still isn’t fully done, while at the same time money is spent on adding more analytics to AMO, on CliqZ, on the Mr Robot addon, and even on Pocket. Which still isn’t ooen source.
Mozilla has betrayed every single value of its manifesto, and has set priorities opposite of what it once stood for.
That can be criticized.
Wow, that escalated quickly :) It sounds to me that you’re already arguing in bad faith, but I think I’ll be able to respond to each of your points individually in a meaningful and polite way. Maybe we can uplift this conversation a tiny bit? However, I’ll do this with my Mozilla hat off, as this is purely based on public information and I don’t work on Cliqz or Pocket or any of those things you mention. Here we go:
As someone who also got into 1-3 arguments against firefox I guess you’ll always have to deal with criticism that is nit picking, because you’ve written “OSS, privacy respecting, open web” on your chest. Still it is obvious you won’t implement an lz4 file upgrade mechanism (oh boy is that funny when it’s only some tiny app and it’s sqlite tables). Because there are much more important things than two users not being able to use their default tools to inspect the internals of firefox.
Sure, but it’s obvious that somehow Mozilla has enough money to buy shares in one of the largest Advertisement and Tracking companies’ subsidiaries (Burda, the company most known for shitty ads and its Tabloids, owns CliqZ), where Burda retains majority control.
And yet, there’s not enough left to actually fix the rest.
And no, I’m not talking about Telemetry — I’m talking about the fact that about:addons and addons.mozilla.org use proprietary analytics from Google, and send all page interactions to Google. If I wanted Google to know what I do, I’d use Chrome.
Yet somehow Mozilla also had enough money to convert all its tracking from the old, self-hosted Piwik instance to this.
None of your arguments fix the problem that Mozilla somehow sees it as higher priority to track its users and invest in tracking companies than to fix its bugs or promote open standards. None of your arguments even address that.
about:addons code using Google analytics has been fixed and is now using telemetry APIs, adhering to the global control toggle. Will update with the link, when I’m not on a phone.
Either way, Google Analytics uses a mozilla-customized privacy policy that prevents Google from using the data.
If your tinfoil hat is still unimpressed, you’ll have to block those addresses via /etc/hosts (no offense.. I do too).
I won’t comment on the rest of your comment, but this is really a pretty tiny issue. If you really want to read your sessionstore as a JSON file, it’s as easy as
git clone https://github.com/Thrilleratplay/node-jsonlz4-decompress && cd node-jsonlz4-decompress && npm install && node index.js /path/to/your/sessionstore.jsonlz4. (that package isn’t in the NPM repos for some reason, even though the readme claims it is, but looking at the source code it seems pretty legit)Sure, this isn’t perfect, but dude, it’s just an internal datastructure which uses a format which is slightly non-standard, but which still has open-source tools to easily read it - and looking at the source code, the format is only slightly different from regular lz4.