Re:Chrome is deploying HTTP/3 and IETF QUIC
by seszett on Thursday October 08, 2020 @11:21AM
(#24719921)
> The world already sees unblockable ads. They're called "Ads by Google" on the first page of Google search results depending on the search query.
I don't see them even when searching for commercial things, so I guess they are blockable (I just have uBlock Origin).
Re:Chrome is deploying HTTP/3 and IETF QUIC
by 1vuio0pswjnm7 on Friday October 09, 2020 @01:45AM
(#24727197)
You are still requesting and receiving the ads as they are part of the results page. View source in your browser to verify. Your ad blocker is probably modifying the page after you receive it so the ads do not display. I can do the same thing without an ad blocker using something like curl and sed. I edit out the ads, then view the page. The parent commenter OTOH is referring to DNS-based "blocking". In that case, the ads come from another domain and because we control DNS the ads are never requested, never sent and thus never received. There is nothing to discard. The word "block" is really not the best term to describe what is happening.
Re:Chrome is deploying HTTP/3 and IETF QUIC
by fomine3 on Thursday October 08, 2020 @09:59PM
(#24725976)
That's OP's point. Anyway DNS-based ad blocker can't block such ads (delivered from same host name as content) but browser extension can. I'm curious why DNS-based approach is such popular even for PC browser.
Re:Chrome is deploying HTTP/3 and IETF QUIC
by pas on Thursday October 08, 2020 @07:19PM
(#24725009)
Could you link to some docs/posts on where/how Google recommends Golang devs to embed a DNS resolver?
Is that built-in resolver somehow configurable? (env vars?)
Re:Chrome is deploying HTTP/3 and IETF QUIC
by 1vuio0pswjnm7 on Friday October 09, 2020 @02:01AM
(#24727271)
Re:Chrome is deploying HTTP/3 and IETF QUIC
by 1vuio0pswjnm7 on Sunday October 11, 2020 @01:04AM
(#24743851)
s/device/& and application/
DNS-over-HTTPS can actually be useful. I can do bulk DNS lookups from DOH servers using HTTP/1.1 pipelining, retrieving thousands of names at a time over a single TCP connection. I can look up every name for every HN item in one go, store this data in zone file served by a localhost DNS server and generally never have to use remote DNS when browsing HN. This makes for fast browsing with a text-only browser.
The issue I am surprised more people are not raising is the decision of Google to encourage Golang developers to use a "built-in" DNS resolver in their applications rather than relying the system resolver and submitting to traditional user controls like resolv.conf, nsswitch.conf and HOSTS. Regardless of the motivation behind this choice, IMO it tips the scales toward developers instead of (non-Windows) users in terms of ease of control over DNS lookups, not to mention the privacy issue (shared by DOH) of enabling a third party DNS provider to segregate lookups by device.