I have CF DNS and the website works correctly for me in Italy so the answer is yes, changing DNS works, even Google's DNS should do it.
But the default ISP ones all block some websites related to piracy, and sadly for most people that’s enough to deter them or worse, it leads them to visit suspicious websites and download viruses.
DNS "blocking" doesn't impress me much; it only works if you rely on the ISPs DNS servers.
I think personal computers should simply ship with a local recursive resolver installed and configured. The resource burden is tiny, and it's likely to be faster than most ISP's resolvers. And it'll tell you the Truth about what's in the DNS tree.
I understand that many ISPs use slow DNS servers as a way of throttling their users.
Some places forcibly redirect all port 53 traffic to your ISP's DNS server, some British ISPs do this if I'm not mistaken. If popular operating systems started doing this, more countries would follow.
DNS over HTTPS would solve the problem, but some countries might outlaw browsers that ship with it if it became too much of a problem.
What kind of "place" can redirect a port-53 request to localhost to my ISP's DNS server?
DNS-over-HTTPS is a move in the wrong direction, if you ask me. There aren't many DOH servers, so it concentrates control even more than traditional DNS. But if you are running your own recursive resolver, the only ways to control the results are to control the authoritative servers (nope), or to control the roots (most of them are physically in the USA, and run by corporations, so that's sort-of possible).
They can't redirect things going to localhost. But how does your local resolver talk other authoritative DNS servers? UDP on port 53. The instant that kind of packet hits your ISP, it's not routed outside their network and is answered by their DNS.
Well, I didn't know they did that. They'd have to use a packet filter to do that; in the normal case, I send my UDP query to the authoritative server via its IP address, and if my ISP doesn't forward the query, then it's not providing internet service, it's simulating it. My resolver respects DNS signing, so I think I'd get errors rightaway if my ISP tried to substitute a forged answer.
My (niche) ISP is rather benevolent; as far as I'm aware they don't block at all, and they brag about providing "real internet service". At any rate, I'm not aware that my recursive resolver has ever encountered an answer that was forged by my ISP.
I’m not honestly certain how big of a hurdle this is. I would figure that if a site is to be blocked, then the ISP substitutes their own “authoritative” response, which would include cryptographic signing details (even pretending their public key is the official one.)
> My (niche) ISP is rather benevolent …
I think most are. In my market, even the big guys haven’t done this, though I have heard about it happening in larger markets when big ISPs are up to no good (like inserting ads or whatever.)
I am running a recursive resolver locally. When it resolves a name, "upstream" means the root servers, not some DNS cache such as my ISP offers. A recursive resolver chases the name down the DNS tree to the authoritative server.
To block that, you have to either tamper with the root servers, or get control of the authoritative servers.
> To block that, you have to either tamper with the root servers, or get control of the authoritative servers.
I don't think so. The ISP can just reply to the DNS packets itself, without sending them to the root servers. Your local recursive resolver will think the response is from other DNS servers but in fact they would all be from your ISP.
You should still not use MONEY in Postgres, even their own website says so [1].
I still wouldn't use floats/numerics/decimals to store currency either in any db generally, as said by others you're going to end up with inaccurate numbers [2].
Therefore using integers is in fact very good for this use-case, especially if you are in accounting or book-keeping!
Source: I work for a Fintech company that processes millions of payments.
I'm Italian, I've tried multiple layouts and keyboards, at the end I've settled on the US one which is better for programming (positioning of the brackets are better) and on MacOS I can just long press to get the accentuated letters.
On Windows I use the US INTL layout and it works really well even for accentuated characters.
Just by typing ` followed by the letter that you want accentuated, for example `e = è, even my non coder friends prefer that layout over the official Italian one.
But your keyboard it's actually pretty good in my opinion, you can write in French, Spanish, Italian, German, Greek and probably a few more languages that I can't recognize, so I would propose to change the name to qwerty-weu (West Europe) since that seems the spirit of the project.
I signed up and I really like the concept and the ideals behind satellite, kudos for that!
But here some of my opinions to improve the experience:
The sign-up should say the minimum amount of ETH required to create an account, I wanted to test the process of getting it from the platform so I used the "Need ETH? We got you covered" button and it worked without a problem.
There are some tiny problem with the UI, for example the font color for some parts of the UI blends in with the background and makes it really difficult to read it, for example: usernames on comments, the network activity (navbar, left of "Media"), titles and icons on the left menu bar on profiles ("Public Earth ID" and "Satellite Data"), bio on profiles, etc...
The landing page looks beautiful, but sometimes it freezes my browser for a second, since it is heavy js, but that might be my fault because of my 200+ tabs open.
I am really curious on how Satellite will expand and scale with more users, especially the constellation page, and once again congrats, you are building the future of web!
Honestly I was just trying their service because I'm excited about a company offering Cloud Service that is based in Europe, this is just one thing I don't like about them, that's it.
Imagine if something doesn't work and you followed exactly the documentation... at first I wouldn't think that there is something wrong with the docs but that I did something wrong on my implementation, that could lead to a lot of wasted time just because the company didn't write his own documentation.
I think that the "trust no password manager" concept goes too far, there are password managers out there that are encrypted and offline, and don't call home, examples are Keepass, pass, etc...
I think that part should be changed to "trust no cloud password manager" especially those who can't be accessed while being offline
Check if their bug bounty program covers it, if not just report that to them and give them some time, if they don't fix it after that time you can disclose it to the public.
But the default ISP ones all block some websites related to piracy, and sadly for most people that’s enough to deter them or worse, it leads them to visit suspicious websites and download viruses.