reCAPTCHA is a rate-limiting measure. Google handles all the heavy-lifting and attacker protection for you, and the slow fade you see in the video is that rate-limiting in action. But if you get a clean CAPTCHA result back from them, then that client is very unlikely to be an automated attacker. It's super easy and scales really well.
Conveniently, normal users with typical browser configurations get nothing but the animated checkbox. For nearly everyone, the whole experience is simple and easy. The only people who get inconvenienced are the low-grade privacy enthusiasts who think that preventing tracking is the path to Internet safety. Ironically, "tracking" is literally the mechanism by which legitimate users can be distinguished from attackers, so down that road lies a sort of self-inflicted hell for which the only sensible solution is to stop hitting yourself.
It's not Firefox that's the problem; reCAPTCHA works just fine on Firefox. It's all those anti-tracking measures you installed and enabled -- they work by making your browser indistinguishable from a low-quality bot, kicking the website into self-defense mode. The slow fade is a rate-limiting measure. It's annoying to you, but it's more annoying to people trying to automate login attempts.
The site is attempting to protect your account by preventing automated attacks against it. Meanwhile your browser is doing it's best to look like a shell script, refusing to send any sort of behavioral feedback or distinguishing characteristics that might give away the fact that you're a human.
So the question is: is it really worth alienating those quirky, paranoid users who take extraordinary anti-tracking measures, just to protect your normal users from automated attacks?
Thing is, Blink is not Chromium, Chromium is not Chrome, neither of them is Google, and BSD-3-clause is a pretty damn solid bulwark against the monopolization of the "control of fundamental online infrastructure", were that to ever become a concern again.
And the other bit is that the building blocks that make up Chromium power a lot of technology that is totally independent of anything under Google's influence, including NodeJS, Cloudflare's Workers, Microsoft's VS Code, and Amazon's Firecracker. They use it because it's solid, well-engineered tech. And even though Google wrote it, Google can't control it or stop you from using it against them. Microsoft isn't ceding anything at all to Google, Google's not in control of anything here.
The uncomfortable truth is that the role of neither Gecko nor Firefox nor Mozilla is particularly critical in terms of protecting the free and open Internet. What prevents Google from going all IE6 with Chrome isn't Mozilla, it's Chromium. If IE had been a BSD-licensed open-source project since 1995, then all the BS we endured in 2002 could never have happened; explorerium would have been trivially forked to create a sensible competitor with no switching cost.
Google tied their own hands from the very beginning, and by ensuring Chromium doesn't lag behind, they're keeping their hands tied. Almost as if they were doing it on purpose. In fact, the fact that Microsoft is switching to Chromium locks both tech giants into an intriguing sort of bargain. Each can benefit from the other's work as long as neither strays too far from the open source codebase, as long as they both push their changes into the open. So you end up with a reasonable guarantee that the future of the Internet stays independent; not because of a nonprofit competitor with a strongly-worded manifesto, but because none of the the main players can afford to make it closed.
I dug into the details earlier this year, and it turned out at the time that Microsoft counts some undisclosed but significant percentage of revenue from sales of Office 365 in their "Commercial Cloud" category, even if you buy it in a box at a store... because in theory that box entitles you to Office In the Cloud. This (Azure plus some percentage of Office) is the "Azure" revenue number that gets compared to AWS and GCP to determine the market share number that you see in all the graphs.
Can anyone confirm/deny? I'm reasonably certain this is right from my reading of financial reports, but I'm no accountant.
This is very true. There are lots of gamification the providers play to “juice” the numbers.
Here’s one example (apologies for picking on IBM). So IBM will sell you a million dollars of software for $1, and then force you to buy $600,000 of cloud even if you never use it. You don’t complain because you got a 40% discount, and IBM can “book” 600k in cloud revenue.
The idea of SMTPing email out from your home ISP turned out to be problematic once spam became a business model. Gmail's not the only place that categorically won't trust it.
You need a mail server. You can run it yourself if you're in to that sort of thing, but you can't run it off a residential/consumer uplink. Sorry, this one's non-negotiable. Then your home server authenticates to your mail server as a client, and send email through your mail server. Your mail server is recorded as the IP address of origin, not your home address. MTAs are already designed to do this with nearly zero effort on your part, so you don't have to change your workflow, just your config file.
Don't want to pay for a mail server? Good news! There's like a gazillion services that actually do this for free. Gmail actually turns out to be one of them. Don't want to have to use Oauth? Good news! Gmail's not the only mail service. There's ten billion others.
It totally should be. If you use SPF and DKIM, that should override distrust of IP addresses. If your domain has good reputation and SPF and DKIM prove that you are authorized to send using your domain, then only the reputation of your domain should be considered (and affected) when processing the inbound email.
> Then your home server authenticates to your mail server as a client, and send email through your mail server.
That just overcomplicates things in that you now have to maintain two mail servers. Just set up a tunnel to route the public addresses of your server to your home server, then you can send directly to whereever using static addresses. Also has the advantage that the TLS is terminated on your own hardware, rather than on systems with potentially questionable security of some cheap hosting provider, so less trust in proper security and data protection practices of the hosting provider is required.
> Don't want to pay for a mail server? Good news! There's like a gazillion services that actually do this for free. Gmail actually turns out to be one of them.
Giving power to Google both over your data and over the direction of email in general is not free. That's the one thing everyone should finally grasp. Using Facebook isn't free, using GitHub isn't free, using Gmail isn't free, ...
>It totally should be. If you use SPF and DKIM, that should override distrust of IP addresses.
There are several IPs that are completely banned on my firewall because they send shitloads of spam over dozens of domains. And some IPs are just inherently not trustworthy (Tor exit nodes, North Korean IPs, etc.)
Everyone can setup a SPF and DKIM record on their domain. It's not hard.
IPs have reputation and you better deal with it because most sysadmins on your receiving end won't deal with any special snowflake configuration.
This isn't exclusive to Gmail, this is basically any mail service and server out there.
> There are several IPs that are completely banned on my firewall because they send shitloads of spam over dozens of domains.
I understand that that is the case. I said that it shouldn't be the case and why. So, what's your point?
> And some IPs are just inherently not trustworthy (Tor exit nodes, North Korean IPs, etc.)
Noone is saying you should be trusting those IPs. I said domain trust should override IP distrust. So, again, what is your point?
> Everyone can setup a SPF and DKIM record on their domain. It's not hard.
Which is obviously the premise of using them to override IP distrust? So ... what is your point?
> IPs have reputation and you better deal with it because most sysadmins on your receiving end won't deal with any special snowflake configuration.
I think I wouldn't write "It totally should be" if that were the current reality, would I? So ... what is your point in explaining what I am obviously aware of?
Also, you might be surprised, but "special snowflake configuration" is how every change starts. So, if your argument were to be taken seriously, we should never have introduced SPF, because the first person to use SPF had a very special snowflake configuration indeed.
> This isn't exclusive to Gmail, this is basically any mail service and server out there.
Erm, yeah, thanks for repeating half a dozen times the obvious premise of my comment.
>Noone is saying you should be trusting those IPs. I said domain trust should override IP distrust.
I don't trust certain IPs. Why should the presence of a SPF or DKIM override my trust of these IPs? If that is the case, why should it be for any other IP?
>Which is obviously the premise of using them to override IP distrust?
Which is my premise for why having them override IP trust is completely useless. There is nothing involved in the process of setting up SPF or DKIM that would make me trust a domain if the IP is not trusted.
Nothing about the presence of SPF or DKIM should override distrust of an IP, just as the presence of an IP shouldn't override distrust of a domain, that's simply confusing different functions. Neither SPF nor DKIM nor IP provide trust, what they provide is identity. Identity is the basis for reputation. And reputation is the basis for trust.
When you use IP blocklists, say, you are effectively using a reputation database that maps an identity (a client's IP address) to a reputation score that heuristically reflects how well the owner of that address space has guarded the address against use by spammers.
Equally, you can have a database of reputation scores for domains that reflect how well the owner of that domain has guarded the domain against use by spammers.
So, the existence of an authenticated domain identity, as established through SPF or DKIM, should override the IP address identity as the basis for determining the reputation of the sender. The identity alone never provides trust, it is only the key for looking up reputation in some database to base your trust on, and to store any reputation feedback under (like, when an email is marked as spam by the recipient). If your database says that my domain is trustworthy, then you should accept emails from that domain even if they come from a tor exit node, and if you determine that it is spam after all, that should lower the reputation score of the domain, not of the tor exit node.
>If your database says that my domain is trustworthy, then you should accept emails from that domain even if they come from a tor exit node, and if you determine that it is spam after all, that should lower the reputation score of the domain, not of the tor exit node.
How would you establish trust in your domain from a tor exit node?
Home connections that send email are 99.9% of the time involved in a spam sending botnet. Those IPs are almost always entirely distrusted.
So you can't build trust into your domain without getting a both a trusted domain on a trusted TLD on a trusted IP.
The identity issue is not of concern since there is no good way to tell if the IP of a domain's mail server changed to a tor exit node because it was compromised, sold or otherwise maliciously claimed or if the owner legitimately did it. Lots of people will therefore treat changing the endpoint for mail as a new identity (for good reason).
>Equally, you can have a database of reputation scores for domains that reflect how well the owner of that domain has guarded the domain against use by spammers.
This already exists, multiple domains. Any spam blacklist operates via such reputation scores. It's utter pain to get your reputation fixed on these once you're in bad standing.
These go for both IPs and Domains. SPF and DKIM are a great way of avoiding trashing your reputation because some spammer is sending under your domain. But we already have tools for reputation.
If you build an IP reputation database, you'll quickly find out that Home IPs will get trash reputation regardless of if you think they should be allowed to send anything. (That's not even mentioning that Home IPs aren't stable)
> How would you establish trust in your domain from a tor exit node?
Presumably, you wouldn't? But just because you can't establish trust this way, doesn't mean you couldn't maintain it that way, does it?
> So you can't build trust into your domain without getting a both a trusted domain on a trusted TLD on a trusted IP.
Yeah, so what? You can't upgrade an operating system without installing it first ... therefore you can't upgrade it? What's your point? Maybe you still need a "static IP" to gain reputation. Maybe someone finds a different solution for building reputation. Why should we keep one unnecessary restriction just because there is another currently necessary restriction? Maybe someone builds a sort of "new domain reputation escrow system"? You pledge 1 bitcoin (or whatever) that gets donated to charity if a panel of judged from the internet community decides that you used your domain to spam, and in return you get a reputation boost in a public database that email servers can check? Who knows, there are endless options for solving that second problem, which really have nothing to do with the first problem.
> The identity issue is not of concern
Erm ... you do understand that without identity, there can not be reputation, right? Even if the only thing you do is that you trust emails coming from a particular IP address because of good experiences with emails coming from that IP address, that only works because the IP address provides identity. The equality of client IP addresses between two SMTP sessions is the only thing that allows you to come to the conclusion that "this is the same entity that didn't send spam last time". This is all about identity and identity only.
> since there is no good way to tell if the IP of a domain's mail server changed to a tor exit node because it was compromised, sold or otherwise maliciously claimed or if the owner legitimately did it.
There is no good way to tell if a domain changed ownership to a spammer even if the IP of the mail server does not change. There is no way to tell if an IP address that didn't spam before changed ownership to a spammer. There never is a way to just know that some identity has not become a spammer. The involvement of a tor exit node is completely irrelevant to all of this.
You never know whether the next connection from an identity with good reputation is spam. You can't. That just isn't how reputation systems work. The point of a reputation system is that it creates an incentive to protect your identity against abuse because otherwise your identity will be muted.
> Lots of people will therefore treat changing the endpoint for mail as a new identity (for good reason).
Well, I can't tell whether "lots of people" do that, but it's certainly a terrible idea. If you have a business relationship with another company, and that company happens to move their email server to a different provider, how would it be anything but a completely braindead idea to penalize their emails for that in your spam filter when the emails are authenticated via SPF and DKIM as still coming from the same domain, and in at least that case thus also from the same company?
> These go for both IPs and Domains. SPF and DKIM are a great way of avoiding trashing your reputation because some spammer is sending under your domain. But we already have tools for reputation.
Yeah, and those tools build on SPF and DKIM ... your point being?
> If you build an IP reputation database, you'll quickly find out that Home IPs will get trash reputation regardless of if you think they should be allowed to send anything.
What is your point? I am not even sure if this is supposed to be an objection?! I mean, a lot of what you write isn't wrong, but just completely besides the point. I suggest that positive domain reputation should override negative IP reputation, and in response you point out that dynamic IPs have negative reputation ... when that is exactly the reason why I suggest that positive domain reputation should override negative IP reputation!?
And no, of course the fact that I think that domain reputation should override IP reputation does not influence the reputation of dynamic IP addresses ... why would anyone think that it would?!
> (That's not even mentioning that Home IPs aren't stable)
Mh, because cars are about moving on roads and boats on water?
Git is a dCVS, so a software to store source code tracking history and users, not a communication platform, mails on contrary are communication platform.
If you want something like Fossil (dVCS with built-in webserver with a mini-site for bugtracking etc) integrated with something like ZeroNet well, we do not have anything like than and yes, it can be an interested thing, far more interested than IPFS monsters etc.
The thing is, in this case we HAVE a solid pictures of every alternative. There's no speculation necessary. We have the "before" and "after" story to point to, and we even have the "alternate universe" story along with it.
Before Android and iOS, the phone ecosystem was pretty mature already. There was more os-level diversity but a lot less choice. It was just half a dozen utterly crappy worlds of lock-in, with barriers to entry that kept newcomers strictly out, and removed any hint of incentive for the incumbents to improve their platform. Remember everything was SO BAD that blackberry actually looked good in comparison? It was practically a parody of monopolistic inflexibility. Regardless of platform, everyone universally hated their phone with such passion that it was a meme in its own right.
Google and Apple both poured a boatload of money into each making a phone platform people would actually like to use. That alone was revolutionary. But each company showed their philosophy in how they presented it:
In the Apple case, the iPhone was shiny and proprietary and carefully presented and DONT TOUCH THAT. You couldn't even write apps for it. You could have web pages, that was enough for you.
In the Google case, Android was open and messy and unconstrained. It wasn't locked down an any meaningful sense; Google originally just kept some basic control of their branding and their marketplace. But without rules, carriers went back to their old tricks, and the ecosystem started to crumble. Remember that almost nobody but Google ever ships "Android", every carrier and manufacturer ships their own fork of Android. And for a long while they were all pretty bloody awful as everyone in the supply chain tried to extract value with preloaded apps, ads, lock-in features, crap hardware, and egregious branding. So using their only leverage (the play store), Google has slowly and carefully been pulling Android back from the brink.
Ironically, sadly, it's exactly these actions Google took to save Android that the EU objects to. They can't see (they refuse to see) the whole picture; they just see the tiny bits they think are relevant. They're like a nearsighted sleuth who finds blood on the floor in a hospital, and arrests the first nurse they see for the murder of persons unspecified. Whatever you say of the evidence they found, they clearly don't even begin to understand the environment.
As for the two companies and their strategies: For Apple, their phone very literally saved the company from demise. They make so much money from selling iPhone hardware that nothing else they do is even important. For Google, going the "open" route with Android wasn't the strategic commercial miracle we like to pretend. But if (and only if) you look at Android as an investment in the future of their Search business, then you can justify the ongoing expense. If you think of how much money it _could_ cost Google in ads revenue to have Apple or Amazon monopolize and manipulate the market, now you've got something huge.
Android can't survive on its own. There's nothing even there to survive; it's not a business. But it can be part of the search and ads business. That's where it can find a niche.
Remember that Android was, and remains today, the ONLY successful open-source consumer operating system, ever. There isn't even a runner-up. Nothing. This is not a business model with legs.
Monopolists have always made the world better initially. Its how they got to be dominant in the first place. In the case of Rockefeller he truly thought he was doing God's work - before him lamp oil was expensive and unsafe. More often than not it burned your house down.
The problem is that without competition stagnation is inevitable.
No, it's functionally equivalent to uninstalling; the only difference is that since the app was installed on a read-only filesystem, the apk can't be deleted. But it's gone as far as the OS cares; it can't be seen or used or run (even in the background) unless the user manually re-activates it.
Android added this capability specifically so that users can remove anything that's pre-loaded, regardless of what any company wants. There's no iOS equivalent because Apple doesn't want to to remove their stuff.
I guess it depends on how "experience" is defined. I had 8 years of "experience" programming before my first full-time paid job.
I am somewhat entertained every time a see jobs requiring 10+ years of experience with Go or Typescript or Swift. It's a sign of just how well-thought-out these postings are.
Conveniently, normal users with typical browser configurations get nothing but the animated checkbox. For nearly everyone, the whole experience is simple and easy. The only people who get inconvenienced are the low-grade privacy enthusiasts who think that preventing tracking is the path to Internet safety. Ironically, "tracking" is literally the mechanism by which legitimate users can be distinguished from attackers, so down that road lies a sort of self-inflicted hell for which the only sensible solution is to stop hitting yourself.