I was a big fan of OCSP-stapling and must-staple. Both of which are slowly being discouraged; LetsEncrypt refuses to issue must-staple certificates since a few months ago, and I think they are shutting down OCSP servers, if not shut down already.
The idea with OCSP-stapling is that the webserver fetches the OCSP data, caches it for TTL ~24 hours, and staples it to the HTTPS handshake. That way, the browser does not need to query the issuer's OCSP servers, avoiding both performance and privacy concerns. Revoked certificates will continue to work for up to 24 hours, but that, IMO, is within an accepted range compared to CRL that can take a lot longer.
The downside is that the HTTPS handshakes now contain a bit more data, and we want to keep this as minimal as possible.
The problem with OCSP stapling is that it either the client has to fall back to doing OCSP checking itself if the server doesn't staple the signature, which has its own problems[1], or enough servers need to support ocsp stapling that the client can just reject connections that don't include it. And unfortunately, there was never a significant uptake for servers, partly because there wasn't really any incentive to implement OCSP stapling. Maybe if there was a TLS 2.0 (or some other standard) that required OCSP stapling and had other benefits as well, it could work.
[1]: the biggest problem with non-stapled OCSP is what to do if you don't get a response for the ocsp request. If you fail open, an attacker can intercept the request to prevent you from knowing the cert is revoked, but if you fail closed, then any issue with the connection to the ocsp server results in loss of service. And then there are also issues with additional latency to wait for the ocsp response, privacy leaks from the ocsp requests, etc.
If the certificate was issued with must-staple flag, then the server can refuse to connect if the handshake did not include an OCSP response.
web servers can refresh OCSP responses in the background and cache valid responses to add some tolerance against temporarily downtimes in the OCSP server.
Right, but the vast majoriry of servers don't use must-staple certs. So browsers would need to do something (even if that something is not checking revocations) for all the other connections anyway.
It's really a chicken and egg problem. Browsers don't want to support must-staple because not enough servers use it. And servers don't use it, because browsers don't require it (or even implement it). And now CAs don't support it, because hardly anyone was using it.
Now if CAs started requiring must-staple, that might push it into widespread use. But that would cause a lot of disruption.
If you're willing to put in the effort to implement OCSP in the first place, why not take the couple percent extra time to add must-staple support? This seems like it would have been a very easy to solve chicken and egg problem.
Browsers and CAs did support `must-staple`. Then they decided to drop support for OCSP altogether, in part because not enough servers were using must-staple (or ocsp stapling at all).
As for server implementaions. Most servers, sure it isn't that much harder to use `must-staple`, if you are already doing ocsp stapling. But most servers don't do the stapling at all, because there isn't a strong reason to, and you need to set up a system to periodically fetch and cache the OCSP signatures, and whatever system you use to terminate TLS needs to support it.
I live in a popular Digital Nomad friendly country, and myself included, work with Europe/American companies roughly matching their time zones.
Now, the people I work with know that I'm not really located in the same time zone, but I know people who don't bother to mention it. I rarely get phone calls, but I have a roaming connection active for banking/OTP/etc. Plenty of cheap cafes with great WiFi (500mbps+ almost everywhere), and several times cheaper too.
Per google, shortened links “won't work after August 25 and we recommend transitioning to another URL shortener if you haven’t already.”
Am I missing something, or doesn’t this basically obviate the entire gesture of keeping some links active? If your shortened link is embedded in a document somewhere and can’t be updated, google is about to break it, no?
About to break it if it didn't seem 'actively used' in late 2024, yes. But if your document was being frequently read and the link actively clicked, it'll (now) keep working.
But as I said in sibling comment to yours, I don't see the point of the distinction, why not just continue them all, surely the mostly unused ones are even cheaper to serve.
I built a URL shortener years ago for fun. I don't have the resources that Google has, but I just hacked it together in Erlang using Riak KV and it did horizontally scale across at least three computer (I didn't have more at the time).
Unless I'm just super smart (I'm not), it's pretty easy to write a URL shortener as a key-value system, and pure key-value stuff is pretty easy to scale. I cannot imagine that isn't doing something as or more efficient than what I did.
Google also has the advantages that they now only need a read-only key-value store, and they know the frequency distribution for lookups. This is now the kind of problem many programmers would be happy to spend a weekend optimizing to get an average lookup time down to tens of nanoseconds.
I don't think it would even cost me very much to host all these links on a GCP or AWS thing, I don't think more than a couple hundred dollars a year.
Obviously raw server costs aren't the only costs associated with something like this, you'd still need to pay software people to keep it on life support, but considering how simple URL shorteners are to implement, I still don't think it would be that expensive.
ETA:
I should point out, even something kind of half-assed could be built with Cloud Functions and BigTable really easily; this wouldn't win any kind of contests for low latency, but it would be exceedingly simple code and have sufficient uptime guarantees and would be much less likely to piss off the community.
If I had any idea how to reach out to higher-ups at Google I would offer to contract and build it myself, but that's certainly not necessary, they have thousands of developers, most of which could write this themselves in an afternoon.
I don't understand the data on ArchiveTeam's page but, it seems like they have 35 terabytes of data (286.56TiB)? It's a lot larger than I'd have thought.
FYI, "TiB" means terabytes with a base of 1024, ie. the units you'd typically use for measuring memory rather than the units you'd typically see drive vendors using. The factor of 8 you divided by only applies to units based on bits rather than bytes, and those units use "b" rather than "B", and are only used for capacity measurements when talking about individual memory dies (though they're normal for talking about interconnect speeds).
Either way, we're talking about a dataset that fits easily in a 1U server with at most half of its SSD slots filled.
The binary units like GiB, TiB, are technically supposed to be Gibibytes and Tebibytes. Thought it was a bit silly when they first popped up but now I find them adorkably endearing, and a good way to disambiguate something that's often left vague at your expense.
In my experience, nobody actually says "Tebibytes" out loud; it's just that silly. In writing, when the precision is necessary, the abbreviation "TiB" does see some actual use.
If that's the unit, I am saying it, but yes - everyone gives me weird looks every time and just assumes I am mispronouncing terabytes but yet does not correct me.
This leaves me wondering what the point is? What could it possibly cost to keep redirecting existing shortlinks that they consider unused/low activity already anyway?
(In addition to the higher activity ones parent link says they'll now continue to redirect.)
In another submission someone speculated the reason might be the unending churn of the Google tech stack that just makes low-maintenance stuff impossible.
Under the section "Software authenticity" does it mention that the secure boot requirement appears to come from article 3, §3 (i).
Quoting article 3, §3 (i):
> radio equipment supports certain features in order to ensure that software can only be loaded into the radio equipment where the compliance of the combination of the radio equipment and software has been demonstrated.
The opening of §3 is:
> Radio equipment within certain categories or classes shall be so constructed that it complies with the following essential requirements:
Still won't lead to a forced disabling of unlocked bootloaders, or making that illegal, mostly because the directive doesn't outright forbid that. But also because of this section:
> (19) Verification by radio equipment of the compliance of its combination with software should not be abused in order to prevent its use with software provided by independent parties.
Put together with the EU’s broader right-to-repair, if any phone manufacturer disables unlocking the bootloader, they're doing so for other reasons, not because RED rules forces them to.
About half of the world population has access to some sort of QR based payment system nowadays.
India has UPI, China has Ali and Wechat pay. Almost everyone in these two countries can go weeks without having to use cash.
In South East Asia, Vietnam is leading QR payments. I live in Ha Noi, and I only carry VND equivalent of $15-20 with me, and it sits in the wallet for ages. Everything from gas stations to restaurants to street vendors to even paying taxes, you do it from a QR code. There is no wallet, the money is directly debited from the account.
Thailand, Singapore, and Indonesia have similar systems. In Indonesia, a couple of "super apps" had their own wallets, but merged with QRIS a few years back, a lot of Indonesian people can now pay with QR codes, even across wallets and bank accounts.
South America and Asia has already started to replace card payments with the QR payments. Rightfully so.
SEPA is a banking infrastructure layer and it is not consumer focused. Also, only ~60% of European banks adopted it. While Pix was mandatory for all banks to adopt and 80% of Brazilian population already used it.
All banks in Euro (currency) countries have adopted SEPA. You might be thinking of SEPA Instant Payments, which is more recent and adotopion isn't universal yet.
I use gitattributes quite a lot (lfs, various diff engines, and export-ignore). Thanks for the heads-up, jj looked very interesting but I'm not going to give up gitattrivutes.
I bet it has higher chargeback percentage too and they probably pay higher fees. iirc if merchant is getting close to 2% fraud to sales ratio, they can get banned for life. It's probably different rules when you're the size of Valve though...
I could be wrong, but Firefox VPN is a relabeled Mullvard VPN, which probably has enough engineers to keep things going well. Plus, it's a VPN service, I imagine a small number of developers is all it takes to keep it up to date.
Edit: It seems to be enabled by default! I've been using Firefox for as long as I remember, and don't setup Firefox afresh frequently.
reply