This is likely because docker runs Linux in a VM on MacOS right?
We've had similar problems with stuff that works on the developers Mac but not the server which is case sensitive. It can be quite insidious if it does not cause an immediate "file not found"-error but say falls back to a default config because the provided one has the wrong casing.
Well completion-ignore-case is enough to solve this particular problem, the other options are just sugar on top :)
I'm going to add completion-prefix-display-length to these related bonus tips (I have it set to 9). This makes it a lot easier to compare files with long names in your tab completion.
For example if you have a folder with these files:
FoobarSystem-v20.69.11-CrashLog2022-12-22 FoobarSystem-v20.69.11.config FoobarSystem-v20.69.12 FoobarSystem-v20.69.12-CrashLog2023-10-02 FoobarSystem-v20.69.12.config FoobarSystem-v20.69.12.userprofiles
Just type vim TAB to see
...1-CrashLog2022-12-22 ...1.config ...2 ...2-CrashLog2023-10-02 ...2.config ...2.userprofiles
$vim FoobarSystem-v20.69.1
GNU Readline (which is what Bash uses for input) has a lot of options (e.g. making it behave like vim), and your settings are also used in any other programs that use it for their CLI which is a nice bonus. The config file is ~/.inputrc and you'd enable the above mentioned options like this
$include /etc/inputrc
set completion-ignore-case on
set show-all-if-ambiguous on
set completion-map-case on
set completion-prefix-display-length 9
I and l also look identical in many fonts. So you already have this problem in ascii. (To say nothing of all the non-printing characters!)
If your security relies on a person being able to tell the difference between two characters controlled by an attacker your security is bad.
I believe that type of stuff is specified in your locale, so it's possible that it would do the right thing if you've set your language to Turkish. Please try it and let us know though :)
If you did it would likely break something as it's one of only two characters not allowed in a file name (the other being null).
You can do a lot of funky stuff within the rules though, think about control characters, non-printing characters, newlines, homographs, emojis etc. and go forth and make your file system chaos!
But that post is Mozilla clearly speaking out against SREN because they do not want to be compelled to block certain sites.
Are you then talking about Google Safe Browsing? Which is enabled by default in Firefox, but which does not "monitor your activities". It compares the site you are about to visit to a downloaded list of known bad ones and warns you if it's on the list. Hardly an Orwellian nightmare. Just turn it off or ignore the warning if you do not want it. I keep it on because I've never seen a false positive on that list and I understand that even I'm vulnerable to attack.
We should be free to customize programs, free to block what we don’t need
And you are. If you don't want to use safe browsing, turn it off, is right there in the menu. They have given you a default that's best for most people and the option to customize.
Further, since it's free software there's really no limit to your power to customize or get rid of what you don't need. (I understand that this is not possible for most people, but that's why you have the menu options, this is just a final line of defense.)
Security for the user is obviously what we are talking about. Regular people do not have the knowledge or patience to make informed decisions regarding their technical security; any model that relies on that is going to fail because people will click whatever they need to make stuff work. Even people who do understand the technology do stuff like disabling SSL verification, rather than going through the effort of adding the new CA to their cert list.
Firefox is not doing the same as Chrome. Firefox is adding a feature to disable unverified add-ons on particular domains to stop attacks from malicious add-ons. Chrome is adding a feature that tracks the sites you visit and shares them with other sites to improve ad tracking.
How are these features comparable at all?
That's interesting. The first site on the list is the self-service login page for Banco do Brasil. Doing a little bit of digging suggests that attacking the users local environment to steal money via self-service is a widespread problem in Brazil. That would explain the need to block all add-ons that are not known safe for a page like this so they can't swap that login QR-code. Here's an (old) article detailing some of these types of attacks https://securelist.com/attacks-against-boletos/66591/
I wish Mozilla would be more transparent about this, but I speculate that they might be provided these domains under NDA from the Brazilian CERT or police.
TBH I think malicious add-ons are the new frontier of cybercrime. Most classic attacks methods are well mitigated these days, but browser add-ons are unaffected by pretty much all protections and all the sensitive business happens in the browser anyway.
remotely monitored their browsing real-time
it’s kind of inevitable that sometimes they have to support that giant
What more specifically are you talking about here? The functionality we are talking about can not be used for remote monitoring. Are you saying Mozilla added this feature under duress from Google?
You can absolutely disable this feature, Mozilla provides instructions for how in their article https://support.mozilla.org/en-US/kb/quarantined-domains
Sadly my experience is that when it comes to security measures, user control often runs contrary to security. While we definitely should have the choice, you have to make it a bit difficult and non-obvious to disable security features, or people will unwittingly disable them for all sorts of bad reasons.
While I don't completely understand the use cases for Mozilla's add-on domain blocklist, I also don't see any reason to assume malicious intent. Malicious add-ons are a very real and serious threat and it's obvious that Mozilla need a way to quickly and remotely protect users. Doing so on a domain level is much less impactful than completely shutting down an add-on.
Since it is obvious to the user if this is triggered, and the user has the option of disabling it per add-on or completely, what's the real problem?
(That said I think it's great that people are being skeptical even of Mozilla)
Edit: Sorry I misunderstood how this is displayed, it is not as obvious as I thought. Hopefully this will be improved. Though doing so might come with the drawback of making unwitting users more likely to disable the protection.
You really can't though. For several reasons. Which would have been apparent to you had you bothered to actually create your example link to http://аpple.com or to understand this problem.