Wow, what a dumb justification for the privacy concerns. URL hashes aren't even sent to the server, let alone have anything to do with DNS. We already put sensitive stuff in URL hashes, like OAuth tokens.
Read again. Their point isn't that the fragment is sent to the server or DNS.
Their point is that you can infer the existence of a certain text on a page the user views (even via https) by sending them a link like this and observing the browser loading resources that would be at the bottom of the page. The only reason the browser would do that is if it scrolled to the bottom, confirming the text you put in the link is on the page.
Yeah -- it's frustrating that the privacy concerns brought up in the article are just blantantly wrong. Especially because there a legitimately interesting issues in the security write-up [1].
On the other hand, I suspect they probably won't get the mitigations for those real issues right the first time. It's a complicated system they're building, and I think someone will find a clever way to break it.
This sentence from the doc referenced sums it up well I think:
> A naive implementation of this feature may allow an attacker to determine the existence of textual content across an origin boundary.
Security & privacy implications of that seem obvious, e.g. extracting an account number (or other sensitive information) from a page by searching for successive prefixes.
Just to clarify, I do think there are real privacy concerns with a naive implement of this feature. Allowing sites to search across origin boundaries would be a huge issue!
I just don't think that the DNS query issue mentioned in the article is the thing to be worried about. It's just so much less severe than the fact that DNS isn't encrypted, and requires essentially the same fix.
Careful about calling something a dumb justification. It's often the simplistic-seeming features that expose unforseen privacy issues, in large part because today's internet is such a complex place. In the end, it may turn out that privacy concerns are unjustified. But dismissing them out-of-hand isn't wise.
"Consider a situation where I can view DNS traffic (e.g. company network), and I send a link to the company health portal, with #:~:text=cancer," he wrote. "On certain page layouts, I might be able [to] tell if the employee has cancer by looking for lower-on-the-page resources being requested."
But wow, what an absurd amount of work to almost find something out when you already have access to the entire network, and apparently the WiFi is not secured at all or your targets are all plugged in and on your switch. This is like complaining about a weak combination on a padlock used to secure your screen door.
It sounds like the feature's enabled across all websites - so it could break security & privacy expectations a user has about existing web pages.
It requires that the attacker has DNS request visibility and expects that a user will visit a vulnerable page - not necessarily huge barriers to entry.
This could be exploited by targeting a user with an advert that appears in the footer of a webpage, for example, and then obtaining DNS logs for that user after-the-fact.
It's a useful feature certainly; the concern is mainly around the fact that this has essentially been self-certified by the development team and rolled out.
With more ISPs looking to monetize DNS logs, and the future of DNS infrastructure looking a little uncertain at the moment, there does seem to be risk here given that it could become widely deployed.
But couldn't you now just buy an ad, send them to ihavecancer.example.com and find that in the DNS logs later? You don't even have to own the domain. You could use that exact one and then just find the failed resolution in the logs.
