user.js: icloud: Did Not Connect: Potential Security Issue [RFP bug: 1621729, 1618537]
Browser: Firefox 93.0 Affected website: https://www.icloud.com/ Screenshot: https://i.ibb.co/ZXxBkRn/screenshot.png Error:
Did Not Connect: Potential Security Issue
Firefox detected a potential security threat and did not continue to idmsa.apple.com because this website requires a secure connection.
What can you do about it?
The issue is most likely with the website, and there is nothing you can do to resolve it.
If you are on a corporate network or using anti-virus software, you can reach out to the support teams for assistance. You can also notify the website’s administrator about the problem.
This error manifested only after implementing user.js I have tried setting the following parameters to false, without however resolving the issue:
user_pref("privacy.resistFingerprinting", false);
user_pref("privacy.resistFingerprinting.letterboxing", false);
Thank you in advance for your help.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 31 (19 by maintainers)
security
https://github.com/arkenfox/user.js/blob/85438d00e457bff692303af519da618c6372476b/user.js#L987
You do not need hide your IP. But it must not be stable over a long time.
A client JS fingerprint we can reduce or suck naive scripts in. Some passive FP we can deal to as well (like some headers). But IPs we can’t - there’s always going to be an endpoint - that’s outside the realm of FF until they add a Tor Window Mode, i.e to achieve that level of IP protection will only come from protocols like Tor that are set up correctly: i.e random exit nodes per eTLD+1.
We are all giving away an IP. It can be collected as the IP address itself, and it makes up part of an overall fingerprint (client properties/active + passive + IP). And that IP can rendered into something more meaningful, or ignored. Such as TB users can be rendered to “Tor”, your VPN can be rendered to “VPN Provider ABC”, your real IP can be reduced to “AT&T Los Angeles” etc. A fingerprint is just a snapshot in time - it can be manipulated after collection to link traffic, and IP is simply one metric of many
Entropy of IP will vary: e.g. your ISP is small in some rural town vs living in the heart of New York - or your VPN only has a million users vs a VPN with 100 million … whether your real IP is static/dynamic … and there are lots of other variables to do with ISPs
Read https://bugzilla.mozilla.org/show_bug.cgi?id=1449732 and eka and tjr’s comments. For the record, I’ve sat in on meetings with Tor Project people, and a presentation to eka, for steps needed to get a Tor Window Mode into Firefox, and there was even a prototype built
Ultimately, Mozilla knows that a proper 100% solution is not just RFP but also Tor. And that there are also many tools in the toolbag. Blocking known FPing scripts is one. Fooling naive ones is another. And with uBO you can control a lot of third parties etc. When you factor those into the equation - then a VPN makes sense, even without Tor.
At some stage we’re going to move to dFPI (instead of FPI which if there is an actual issue logging in, this would fix that), and at some stage they might fix the RFP issue(s) with icloud (looks doable IMO)
Referers you can work around by using Smart Referer in hard mode and whitelist icloud<->appleid (or whatever it is). And the OSCP one varies person to person
So all up, until then, use a secondary browser - I have nightly here with just uBO and a couple of basic tweaks, which I use for testing and the occasional one off sites. Works a treat
Because we enforce it.
https://github.com/arkenfox/user.js/blob/85438d00e457bff692303af519da618c6372476b/user.js#L512-L519
Firefox defaults to “check if the cert is still valid, and if the check fails ignore it”. This mean privacy leak and no real security gain.
also see https://bugzilla.mozilla.org/show_bug.cgi?id=1618537 (but that’s also RFP related)
its RFP’s timing protections
There’s a bugzilla somewhere… https://bugzilla.mozilla.org/show_bug.cgi?id=1621729