search

BrowserWorks / Waterfox

The official Waterfox 💧 source code repository
https://www.waterfox.net
Other
3.84k stars 341 forks source link

About the leak (resource) #235

Closed WagnerGMD closed 6 years ago

WagnerGMD commented 7 years ago

Hello,

I'm wonder when do you plan to fix this trouble ? If you want to check it, you just need to open this page and you will get the same result as on this picture.

In the past, that's right the addon No Resource URI Leak_v1.1.0 was a good solution. But it doesn't work anymore (since Firefox_v55 or Firefox_v56). Despite the fact : yes one new version exist, it wouldn't be better to just include the patch ? Because it was already done with Firefox_v57 and I don't see the point to wait (or avoid).

Kind regards.

jugi1 commented 7 years ago

I agree with WagnerGMD. Any solution or alternative?

MrAlex94 commented 7 years ago

It's patched in v56.

L-a-n-g-o-l-i-e-r-s commented 6 years ago

@MrAlex94 It's not fully patched, the test page shows me in comparison to No Resource URI Leak 1.2.2 (Custom version from a repository topic somewhere on the ghacks js file github.)

While the extension is disabled, it isn't revealing the extensions any more in WF 56, however it is revealing the following without the extension enabled: Platform Detection, Default Locale, Firefox ESR Channel, firefox.js, firefox-branding.js, firefox-l10n.js, webide-prefs.js and greprefs.js, (The js files have hashes which are uniquely identifiable, it is able to not only count the number of strings but display all of the settings. For example, firefox-branding.js contains links to waterfox that identify the browser as not being MFF) all of these are not exposed when the extension is enabled.

I don't know if it's 100% fixed in FF 57, I have heard some mention this, but I figured I would mention this.

https://browserleaks.com/firefox 🎱

--

WagnerGMD commented 6 years ago

Perhaps there is something wrong in No Resource URI Leak_v1.2.2 ? I haven't heard about (but on the moment it was fine with No Resource URI Leak_v1.1.1) It's true about Firefox_v57, because a few weeks ago I haven't met any trouble. So as today I will assume nothing has change.

L-a-n-g-o-l-i-e-r-s commented 6 years ago

@WagnerGMD

No, there was some additional changes on a repository link posted in the topic 1.1.1 is from on the ghacks.js script issues forum. It's marked as closed I think on the ghacks.js repository if you're looking for it, I don't have the link on me.

If I recall, the changes to 1.1.1 were to fix the relative path issue with xpcom/xul after FF 56 dropped, 1.1.2 added webextensions hiding to it if I recall, the white list for the webextensions doesn't work if I recall based on the post, but that is irrelevant to me as I have found everything to be working with webextensions (from what is enabled anyway in 55.2.2 WF. (Web extensions generate persistent random ID's which are even more identifiable. *last I checked.)

I don't know what you're talking about with something being wrong, some enhancements were made to the extension, not fully implemented but helpful, I built it from its source and titled it 1.1.2 for my library.

What I said about specific resources still being exposed in 55.2.2 in response to @MrAlex94 is still true, this can be tested with the extension disabled. It reveals lots of detailed information like settings configurations, it would easily identify the browser as WF and those files all have unique hashes so it makes you uniquely identifiable. The issue is not fully resolved and in my book is as trackable as before, even without exposing the XUL/XPCOM extensions, it looks like webextensions aren't exposed either, so that part of @MrAlex94's patch seemed to have worked there. (Unless something is wrong with the testing site or it hasn't implemented checks for exposure of webextensions, in which case, 1.1.2 is the way to go.)

:cactus: :8ball: 😞

WagnerGMD commented 6 years ago

As examples I was meaning :

There is a confusion ? Because no there is a difference between the both (Waterfox_v55.2.2 and Waterfox_v56). According to the name and these links :

I will conclude it's normal (Waterfox_v55.2.2 wasn't fixed and you will need the addon). Because it wasn't yet announced (Waterfox_v56 isn't ready neither published).

"My apologies for the delay in release of v56 which should have happened earlier this month. Had fallen unwell but back at full capacity now! Will reply to all your queries and get the release out ASAP"

That's one recopy message from this link (date is 18 november 2017): https://twitter.com/Waterfoxproject/status/931963434761183237

L-a-n-g-o-l-i-e-r-s commented 6 years ago

@WagnerGMD I don't understand what you're contesting here about my post, I simply stated that the fix implemented in Waterfox 55.2.2 was not sufficient enough. That unfortunately, @MrAlex94 reply was incorrect, because without the extension, very finger printable files were still being exposed, as I explained in my other post. " MrAlex 94 : It's patched in v56." (v56 isn't out, we're still on 52.2.2, that was not made clear, easy for one to get confused with the versioning numbers since FF was 56 recently now 57.)

I explained that you need to use the No Resource URI Leak clone (such as the one you posted 1.1.1) or build the newer one that includes web extensions, although, the white listing is broken for web extensions with 1.1.2. (The clone is needed because the original broke due to something about indirect or direct paths, it was corrected in the clone version of the extension.)

I'll not be commenting further on the subject, it was meant to be informational for other users, as I had been under the wrong impression and disabled the extension when I moved to WF 52.2.2. A warning to users who read this and thought the problem was solved.

😞

WagnerGMD commented 6 years ago

You don't seem to understand. Sorry I won't be there to argue (not my aim). Just one last advice : read it again and very carefully. Then perhaps you will understand (in the news the word security != leak resource).

~~Unless you need a long answer ? From my point of view, the versioning numbers isn't a reason to get confused. I won't be agree. Because for me, the difference is very clear (between Waterfox_v55.2.2 and Firefox_v56). Take it as one simple fact : no there aren't the same number (read again the title from the last article, it's just obvious).~~ By the way, you're confusing because the fix wasn't implemented in Waterfox_v55.2.2. Sorry but did you read it carefully ? According to the lates news, these patchs are only about the security. Then no it doesn't concern this trouble (known as leak resource). Il will be implemented in the futur that's why @MrAlex94 was refering to Waterfox_v56.

Update 14 December : The patch seem's to be missing... So the trouble still exist for Waterfox_v56. I had check also Firefox_v58_Beta11 and no trouble.

Update 16 December : Waterfox_v56.0.1 has been published but according to this page the trouble wasn't corrected.

Update 8 January 2018 : Waterfox_v56.0.2 has been published a few days ago. And apparently, the patch is again missing. Did they read the update or didn't receive the notifications ?

Update 26 January 2018 : Waterfox_v56.0.3 has been published and no it doesn't seem to be corrected.

WagnerGMD commented 6 years ago

Actual behavior

http://nsa39.casimages.com/img/2018/02/28/180228051921800212.png

Expected behavior

http://nsa39.casimages.com/img/2018/02/28/180228051922647994.png

Update 28 Feb 2018 : Waterfox_v56.0.4 has been published and no (as you can see on those picture), it wasn't fixed. At the contrary, the trouble was fixed a long time ago by Firefox (and it was confirm when Firefox_v57 was published. Today, nothing has change because this trouble doesn't exist anymore even with Firefox_v61).

L-a-n-g-o-l-i-e-r-s commented 6 years ago

Update March 26th, 2018: In Waterfox 56.1.0 the issue still persists. I also identified the fork I used for No Resource URI Leak "1.2.2**" (it's not titled that, but for all intensive purposes it is as a fork, it adds web extension unique identifier hiding, unfortunately whitelisting for webextension pages won't work, but at least that version will hide those as well. You must compile this fork from source. https://notabug.org/ilikenwf/no-resource-uri-leak/ (fork of fork)

A whole cache of information is still available including everything you've tweaked in preferences.js, HIGHLY unique and fingerprintable. fix is needed urgently. PSA :warning:

Peacock365 commented 6 years ago

FIXED BY THE FOLLOWING COMMITS:

grahamperrin commented 6 years ago

Please, are you certain that those five fix the issue? All were made (committed by Alex) in 2017.

Peacock365 commented 6 years ago

@grahamperrin

Yes, I am certain. Mozilla has fixed the issue when they released Firefox 57 (November 2017). GitHub of course copies the original date of the commits, yet @MrAlex94 has only merged the commits recently. The original dates remain as Alex chose to mention the original author of the code, which I think is good GitHub practice.

grahamperrin commented 6 years ago

@Peacock365 thanks, now I see the five matches for Bug 863246 under Commits on Apr 30, 2018.

Still, I'm curious, because I always think of things on a timeline: how would I navigate from e.g. https://github.com/MrAlex94/Waterfox/commit/9681c0811d4b66f8f07dcf9a2d9ac465b0918d9d to the April 2018 point on the timeline? I mean, which link/button would I use?

(Sorry for hijacking/going off-topic. Just, this is new to me.)

Peacock365 commented 6 years ago

@grahamperrin

I agree that the system is pretty confusing. If a person A submits an old GitHub commit, and chooses to mention the original author B, the commit will appear amongst the newest commits in the repository of A, but will still have the original date of B's commit regardless.

Why? I don't know. GitHub should stop this practice and should start to always show the commit time of person A's commit, if you ask me.

grahamperrin commented 6 years ago

Thanks / apologies for going off-topic

WagnerGMD commented 6 years ago

Update 17 May 2018 : The first release of Waterfox_v56.2.0 has been published (it's mostly a test build). Apparently, @MrAlex94 (or the team) has finally made a good job. Because as you can see on this picture, for me now the trouble has been corrected (for the record : under W10 v1607). So thank you (because now I believe I can remove this addon).

WagnerGMD commented 5 years ago

it wouldn't be better to just include the patch ? Because it was already done with Firefox_v57 and I don't see the point to wait (or avoid).

Yes, I am certain. Mozilla has fixed the issue when they released Firefox 57 (November 2017).

Just to confirm @Peacock365 the fact, it was true and I was certain too (like I said in my first post). I decide to wrote this message because to remember 2 facts :

MrAlex94 commented 5 years ago

Honestly at the time I thought the patches had landed for v56. And it's easy to verify the claim, please check the commits Peacock linked to, the core of patches which landed June 8 (the rest related to debugging tools and tests. June 12, Firefox 56 was merged to central as shown here. (Of course, they weren't actually merged until Firefox 57 became central). So when I checked at the time, I saw the commits and assumed it was all fine and dandy.

And I didn't come back to this issue until I saw it again in my inbox. Just a FYI, this is what my inbox looks like related to issues, before I move them to the GitHub issues tag, they're in my inbox along with dozens of other emails. It takes time to read through them all!

I am more than happy to have professional discourse, but you are just rude with your comments, especially just to come here to call me a liar. Unfortunately I am a human and fallible. Maybe that should be considered the next time you want to come here and be indecorous.

grahamperrin commented 5 years ago

A link to change logs was shared a few weeks ago, a day after the new web site went live: https://www.reddit.com/comments/beomqj/-/el91umc/

five matches for Bug 863246 under Commits on Apr 30, 2018.

These should be easy to find, by date, through today's revision.

HTH

WagnerGMD commented 5 years ago

Honestly are you totally blind ?

Did you forgot ? The people trust your world and form my point of view, you lie to everyone (as reminder the 7 october 2017). Because a real professional is able :

To resume, you have lost my trust @MrAlex94 and yes that's a good reason to be rude. You didn't guess ? You had lost the trust from several people and they won't provide help anymore.

Do you deserve more explanations ? To conclude, today I was thinking my reply will be very short (a few lines) : Basically too much sign of disrespect and mistakes. That's why the anwser is no !

Despite the fact, I was absent for a very long time. Nothing has changed and it's even little worst today... Now I had just discovered that you didn't even check the commits because on the moment, you have just assumed "it was all fine"... That's another good reason to be rude, no ? Damn right !

Now to finish, you can blame the humans guilty of betrayal (no you aren't the only one). That's all folks !

MrAlex94 commented 5 years ago

Strange that you felt the need to reply after 6 months. I think I was more than fair in my previous reply, which you seem to have ignored.

I'm going to reply to the fact you keep calling me a liar. First of all, I explained before my reasoning for believing the fix would land in v56. Also please note, lying usually is done deliberately with the intent to deceive. My misunderstanding was not that.

Honestly you seem unjustifiably over aggressive, and seem to have a massive chip on your shoulder.

Now I had just discovered that you didn't even check the commits because on the moment, you have just assumed "it was all fine".

What are you on about? There are so many platforms I have to test commits on - and I didn't push any wide updates, so I'm following correct software practices. There was no harm - what's the big deal? I don't think you understand how hard running a project this size is by one person. Thankfully I have people who push commits and help the project, otherwise it would be even harder!

Such an odd rant. Honestly, I'm more than happy to have discourse with people, even if it's about things that are unsatisfactory - but with the way you behave, your loss won't be a noted one.