E.G, if you're using firefox:
https://support.mozilla.org/en-US/kb/change-fonts-and-colors...
133 karma · joined March 11, 2022
cmVsaWVmY3Jldy5uZXQK
E.G, if you're using firefox:
https://support.mozilla.org/en-US/kb/change-fonts-and-colors...
That said, if you created a great tool perhaps it could eliminate the need to create a harness each time. However, I still feel this is most likely an instance of so-called "bike shedding".
You ask a good question at the end:
> do most people rely on other methods (Cypress, mocks,
and if you ask that of yourself I think you'll at least be able to narrow the scope of your idea. For example... why don't you just use Selenium to help recreate the test and save the 30-90 minutes? Perhaps this will help you find what the other tools are missing that will help differentiate yours. IDK
In any case, I don't want to discourage you. So, if you still love the idea I suggest you build a simple prototype for yourself. Then, see if you find it especially useful and pass it around for others to evaluate. It could turn out to be the greatest thing since sliced bread, you never know.
Quad9 uncensored 9.9.9.10 149.112.112.10
FDN 80.67.169.40 80.67.169.12
DNS.WATCH 84.200.69.80 84.200.70.40
OpenDNS 208.67.222.222 208.67.220.220
Google 8.8.8.8 8.8.4.4
Yandex Basic 77.88.8.8 77.88.8.1
AdGuard DNS 176.103.130.130 176.103.130.131
Oh no... that's how you get to Broadway, sorry.
For some reason xenial's nut-server package is missing "/lib/systemd/system-shutdown/nutshutdown"
I had to set-up the ups w/ a newer Ubuntu release, test and trace using "upsmon -c fsd". And then, after comparing filesystems, realize the file was missing from xenial and simply copy it over.
It took much longer than I'd expect due to the breadth of nut, not knowing if my hardware or conf settings were to blame (they weren't), and the expectation that things should "just work".
I know, I probably shouldn't have a machine still running xenial :-P Alas, all is well now, and I've kissed apcupsd goodbye.
.
├── subdir
│ └── test2.dat
└── test.dat
1 directory, 2 files
If you don't use double quotes then the shell will expand test* to be test.dat and the final command will actually be: find . -name test.dat
...so the file named "test2.dat" in the sub-directory therefore won't be found.Instead of using double quotes you can escape the asterisk so it won't be processed by the shell, e.g.
find . -name test\*This was a pretty long time ago and these days I'd consider an existing tool like: https://lstein.github.io/Net-ISP-Balance/
There are many possibilities. I'd, personally, refrain from using the words "tampered" and "attacks" since they carry a moral implication.
It also seems it could be that a name based virtual host configuration changed mid session. I suppose this could be considered routing in a sense as well.
Again, the fact that it hasn't happened often and that your memory/knowledge of the exact transaction of packets is likely incomplete, makes all this just speculation.
My guess is it's probably just a glitch and nothing nefarious is going on. I wouldn't be too worried.
It's good you're keeping an eye on things though!
Well, it's certainly difficult to speculate as to the causes of these past events. I can think of a slew of reasons you may have had the experiences you mention; ssl stripping being just one of them.
So, without being able to reliably reproduce the problem, I'm afraid your only recourse will be to stay vigilant and... have investigation tools ready (e.g. wireshark) for the next time it happens.
Does this mean you don't want to run JavaScript at all? Ever? That's a pretty tall order in today's world. I can understand having JavaScript disabled by default. But that said, JavaScript can be useful for what you want.
I know this because I empathize greatly (except I prefer light mode). In any case, when I saw this comment:
https://news.ycombinator.com/item?id=32719488
in a previous thread, I immediately created the appropriate bookmark-let so that my eyes wouldn't go crazy trying to read dark-mode pages.Maybe it can serve as a solution for you too if you're willing to compromise a bit.
https://help.dnsfilter.com/hc/en-us/articles/1500008110182-transparent-proxying
But, the latest versions of FireFox use DNS-over-HTTPS by default: https://support.mozilla.org/en-US/kb/firefox-dns-over-https
So, assuming your FireFox is up to date, your machine's DNS settings won't play a role. Perhaps you should try disabling/removing browser plugins and/or try a brand new profile?Often captive portals will restrict certain kinds of traffic (e.g. by blocking ports) just "because". However, bear in mind there are financial incentives and ramifications to "free internet". So, every provider tries to lever things in one way or another; this includes cell-phone companies and ISPs themselves. DNS hi-jacking is a good example.
All that said, the combination of ways networks can be configured (both yours and that of the captive portal) are enormous. And, most likely this is what's causing the pain... I empathize.
In this specific case, if you're not already doing so, I'd consider trying a tool which could help at certain locations/providers. I've heard good things about Gnome's network-manager-applet. And, like you say, keep your phone's hotspot nearby just in case.