TPS

@artemiv4nov Given the Waiting for data label you've just added, is there anything else _I_ can provide? Also, given this breaks functionality, I'm unsure that Enhancement is _quite_ right.…

Give me a set of instructions of how to test a potential workaround (since I _am_ affected), & I'll report back. E.g., ifF that `$network` rule could work, lemme know....

>We cannot reproduce this issue on our side, and tbh, I really doubt it has anything to do with QUIC @ameshkov Do y'all test the Google apps against their "testing"...

It's _Google_.… They virtually forced [HTTP/2](https://en.m.wikipedia.org/wiki/HTTP/2) onto the 'Net. D'y'all _really_ think they'll have much trouble w/ [HTTP/3](https://en.m.wikipedia.org/wiki/HTTP/3)? I'll try that rule a little while & report back.

Huh, it's still blocking QUIC for Photos.… Does adblocking need to re-enabled on the app for the rule to be applied?

Using the filter rule above, QUIC is _still_ blocked for Photos.

> Well, HTTP/2 still falls back to HTTP/1 if unavailable. The same is true for HTTP/3. All I can currently report (watching the AG filtering log live) is that now...

@ameshkov 🤯 Yes, it does. It works precisely as you describe — `quic` connection fails, then pulls DNS & falls back to normal HTTPS — which I'd _never_ seen before....

Sent. Do lemme know if y'all find anything. 🙇🏾‍♂️

> 1. The most important question is can we run install the apk in the background? If we can, we should simply implement the auto-update. @ameshkov No-interaction auto-update is now...