pimterry

Much prefer the Broccoli2Shell name & site (for the same vuln): https://broccoli2shell.com/. For starters, I'm pretty sure you can hit this without HTTP if you do any manual Brotli decoding, HTTP just happens to be the most common case that comes up.

I think there's a real argument for trying to push "user must be able to control their device's trust anchors" as the next right to repair battle.

If you don't, you can never tell what a device is sending/receiving, and devices have a hardcoded end-of-life date where they become useless. Would love to see groups starting to push in this direction.

I don't think that applies here. The trust store contains the _root_ certificate, not these intermediates.

The main eMudhra root cert backing these intermediates is "emSign ECC Root CA - G3", which was issued back in 2018 and was widely trusted for TLS way before these intermediates were created. The certs were also cross-signed by Sectigo using their "AAA Certificate Services" which was issued in 2004 (!!!) and was trusted in TLS stores until 2025 (after that it got removed/demoted to email signing only, depending on the store).

Everything which trust one of those roots will trust the intermediates (putting aside revocation, CT checks, lack of ECC support, etc) so the window is much much longer. The AAA does expire at the end of 2028 though!

> I find difficult to understand why intermediate certificates are present in trust stores.

They're not generally (there is a specific case of preloaded intermediates, but that's not the main problem here). The certs here aren't in any trust stores I'm aware of directly. The key change to mitigate this is indeed revocation, but that's hard, because many non-browser clients don't actually support revocation in any functional way.

Firefox has gone further though, and distrusted the corresponding root completely in their store. That's not strictly required if you support revocation for the intermediate, but their trust store is widely reused elsewhere and this guarantees the certs won't be trusted even without revocation support. And honestly everybody is now suspicious as hell of eMudhra, so they'd rather be over cautious.

Google Cloud outage: https://status.cloud.google.com/index.html#status-table

Revolut uses Google Cloud: https://cloud.google.com/customers/revolut

Revolut Business is also down, which does business banking including payment terminals & online subscription processing, so this is going to disable quite a few businesses, in addition to normal consumer payment flows.

They've been expanding hard across Europe recently, this might dent people's confidence in these new fangled neobanks a bit...

From their last filings, they have 70+ million individual customers, 850k business customers. Highest in the UK: about 13 million, so nearly 20% of the population. Ouch.

Partly yes, but I also I think more than expected Node has been able to fix a lot of the warts itself within the existing model, which really undermines the niche further.

The Cloudflare side is also worth a read: https://blog.cloudflare.com/deno-joins-cloudflare/

> I’m happy if this means Deno is able to get a second impulse

Bad news, sorry, the article says:

> We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime.

Sounds like Celld will live on within workerd, Deno is over.

Currently no rate limiting, I might if I have issues in future, but right now it's vastly overpowered for the traffic and extremely cheap to run.

If you want to hit it hard, or you just want to avoid any risk of limits in future, it's a one-liner to host it yourself with Docker: `docker run --rm -it -p 3000:3000 httptoolkit/testserver`, then open http://example.localhost:3000/. Advanced config options for CAs etc are in the GitHub README.

Same server also has an endpoint for that: http://no-tls.testserver.host. Sends RST for any attempted TLS connections, so clients always fall back to plain HTTP.

Also as a _long_ list of other specialist TLS endpoint configurations if you're interested, which can be arbitrarily combined, see https://testserver.host/#tls-endpoints.

That gives neat tricks like https://tls-v1-2--expired--incomplete-chain--http2.testserve...: only accepts TLS 1.2, then sends an expired certificate but fails to send the intermediate cert for the chain (so the client must infer it) and then negotiates HTTP/2 for the connection on top. Fun!

For the desperate people whose tests all just broke, I have a page on my public endpoint testing server that exactly reproduces the classic design: https://example.testserver.host/. You can just use update the URL and go back to blissful ignorance.

Also open-source and self-hostable: https://github.com/httptoolkit/testserver. Lots of other endpoints too, full docs here: https://testserver.host/

This would be a neat API for a digital photo frame - just print photos to it and they appear on the screen.

In almost all cases they will work, just slowly. There's always some power, and almost always some data (power-without-data cables exist, but they're very rare, mostly a specialist security thing).

If the power isn't enough to power a device, that's annoying, but it's strictly better than when we had a unique power cable per-device. We've replaced "carry a charger per device" with "carry one charger for your highest power device, and it can do everything else too". And even with just a low-power cable you can usually trickle-charge overnight or something.

The only optional feature you'll run into that may or may not work at all is monitor support. Would it be better to have a whole different USB-C2 spec which requires display support (and so is significantly more expensive)? If the connector is the same you have the same problem (it's just labelling) and if it's not that sounds like you've just invented display cables which your monitor almost certainly supports today anyway.

> A USB-C cable should be a USB-C cable should be a USB-C cable.

This would completely defeat the point.

There is a range of needs for cables. Some devices have simple needs for power/data transfer/extra functionality, and some devices have more. A $3 USB-powered lamp does not need a cable for gigabit data transfer and 100W charging - this cable would be more expensive than the product. Similarly, new features & performance levels will emerge and we want to be able to use these in new cables backward compatibly.

Given a range of needs, you have two options:

- A single cross-compatible connector, but with a range of capabilities

- Different types of connector for every capability

We used to be in the latter situation, USB-C is an attempt to do the former. Having different capabilities for same-shaped cables is the goal.

Labelling would be great, but standardizing one single spec for all cables would defeat the point.

Trusted staged publishing helps a lot: you have to independently pwn the workflow _and_ then complete a separate 2FA flow as a maintainer. The workflow never sees any keys that can publish independently.

They are allowed to set caps, I've seen them down to around €5000 per transaction so it's not literally all transfers. Still free to transfer above, just takes more than a few seconds to do so, presumably for fraud/theft protection. Some banks will make that a daily limit, or configurable, there's some flexibility but they're mandated to justify all limits with no arbitrary discrimination against instant transfers.

In practice, obviously most personal payments are well under that margin, so within-EU bank transfers are defacto instant everywhere. Most banking apps I've seen don't even show an 'instant/slow' option any more, it's just all instant.

One counter-example: in Spain no language test is required for permanent residency, only for citizenship.

It's an anti-competitive concern all the time.

If we gatekeep service access to specific implementation attestations, it becomes much harder for new implementations to emerge. It doesn't really matter who controls the process.

In that sense, it's always bad. In this specific scenario for example it directly blocks emergence of alternative Android ROMs and Android-mostly-compatible devices like the various Linux phones.

There may be times where that downside is worthwhile, but it's always a downside, and we should very strongly discourage attestation wherever possible on that basis for the health of both the tech ecosystem and the business market around it.

There's a compatibility list at https://privsec.dev/posts/android/banking-applications-compa....

I think the challenges here exist but the reality is overblown to be honest, the vast majority of banking apps (everything that isn't struck through in that list) work just fine.

Fully agree the concern is discouraging adoption though. I would love to see more of a solution here, it seems like purely anti-competitive behaviour by Android that will block competitors emerging.

I mean sure, I'm not intending this to be quoted in a court, honestly I would say all my online comments are irrelevant phrases!

That said - it is their business, they're broadly well reviewed, and they're clearly incentivised to give scrubbing your data out a good go.

More generally, if you're in a jurisdiction with GDPR-like rules (which is a lot of the world nowadays) the brokers themselves have formal policies & tools for removing your data and chasing people manually myself occasionally I've found it quite effective.

You're certainly not going to get anything removed from any three-letter agencies or purely malicious people. Most of the discussion here though is around data brokers, who are generally large serious businesses who will at least follow the letter of the law. You've got pretty good odds of getting your data removed from any non-trivial businesses, if you follow their carefully hidden data collection policy links and then quote your local legislation and their privacy team in a polite but firm (and repetitive) way.

Never used them, but I ran into https://incogni.com/ yesterday.

It's a paid service, they track data brokers datasets (I assume they just act as a buyer for as many as they can) and then manually request your removal from all of them, and then aggressively follow up and chase it for you. Interesting business model, even if it's annoying that the world means you need it.

Some scepticism here I see, but personally I think this is spot-on. I've been keen on a dumber phone for a while, but losing whatsapp & maps makes it a non-starter for any real use. This is an excellent middle ground. The aesthetic is cool, and building this on Sailfish but with Android compatibility is awesome. Big fan of the concept.

> Today, in 2026, as a Spanish resident, I still can't access https://www.womenonweb.org/. Why? Who knows anymore. Fucking money + religion owns our digital spaces now, been for a long time, no one seemingly noticed.

I didn't know about this, so I looked it up: it's because they sell prescription-only abortion medication and ship directly to consumers, where it's legally only available via prescription and medical oversight. Fundamentally they're blocked for ignoring medical regulations. There were some appeals, but the argument is that access to abortion medication is already a well-protected right, so that this is dangerous and unnecessary, and it's not possible to block that while unblocking the rest of their educational resources.