Something being known doesn’t mean a solution exist.
Computing the the set of Unicode characters that would result in a homograph of a latin alphabet word is non trivial. Now do this for relevant/trusted domains, now put in place a mechanism to mark a domain as trustworthy that also minimises your liability.
> Something being known doesn’t mean a solution exist.
But we aren't talking theory. In this case solutions exist, just not in this app?
Also, the triviality point is puzzling, are we only allowed to criticize professionals for trivial fails? (though using a different font is one of the trivial mitigations)
> that also minimises your liability.
How is that a factor, what is their liability now without any mechanism and will it increase if they add some?
Yes, and the industry has been responding to it since approximately 5 minutes after Canter & Siegel started cranking out that green card spam in 1994. We have SPF, DKIM, DMARC, etc. _and_ more importantly, the victim in this case was using Google's mail client to access Google's mail service so they don't even need complex protocols designed to inform 3rd parties about whether a message is legitimate. If Gmail refused to accept any messages claiming to be from google.com which didn't originate from their servers, it'd be quite defensible given the ratio of attacks to the handful of legitimate cases where someone needs to do something like post to an outside mailing list using their @google.com email address.
They don’t have great North American peering. If you happen to be there and are unlucky, you won’t be able to get a very reliable/fast connection to the server.
I tried to use one for Borg backups a few years ago and just ran into endless transient connection issues.
It's more like $2 a TB in the larger plans. I have 5TB there and it's been working great. I use Borg Backup so the data is all encrypted. If anyone cares, Digital Ocean also makes new customers send their ID.
For stuff like archive and backup you can use ovh object storage infrequent access. Comes to 5$ per GB but you pay for what you use only and it scale infinitely.
When you are unmarshaling json, empty map/slice is something completely different than a null or no value present, as you are losing intent of the sender, in case of JSON REST.
For example, if my intent is to keep the present value, I will send {"foo": 1} or {"foo": 1, "bar": null} as null and no value has the same meaning. On the other hand, I might want to change the existing value to empty one and send {"foo": 1, "bar": []}.
The server must understand case when I am not mutating the field and when I am mutating the field and setting it to be empty.
On the other side, I never want to be sending json out with null values as that is waste of traffic and provides no information to the client, ie {"foo": 1, "bar": null} is the same as {"foo": 1}.
Protocol buffers have the exact same problem but they tackle it in even dumber way by requiring you to list fields from the request, in the request's special field, which you are mutating as they are unable to distinguish null and no value present and will default to empty value otherwise, like {} or [], which is not the intent of the sender and causes all sort of data corruption.
PS: obviosly this applies to pointers as a whole, so if i have type Request struct { Number *int `json:"number"} then sending {} and {"number": null} must behave the same and result in Result{Number nil}
I still don't get the line wrapping hangup. Doesn't every modern text editor have an option to auto wrap existing text? Why should I manually limit text to an arbitrary 72 character width between newlines?
