Chrome deploys deep-linking in latest build despite privacy concerns
theregister.co.uk
Chrome deploys deep-linking in latest build despite privacy concerns
1–10 of 159 posts
Re: Chrome deploys deep-linking in latest build despite privacy concerns
#2The quote about DNS seems wrong to me
""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.""
I thought DNS requests just get the domain, not the hash and not even the page requested.
But lets play along. How would sending a link tell you anything apart from if a user clicked said link? How would links to existing anchors example.com#h3-subtitle be any different?
Re: Chrome deploys deep-linking in latest build despite privacy concerns
#3The quote about DNS seems wrong to me ""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."" I thought DNS requests just get the domain, not the hash and not even the page reque…
also #fragments aren't sent to the server at all, unless this changes that (a major major change if so)
Re: Chrome deploys deep-linking in latest build despite privacy concerns
#4The quote about DNS seems wrong to me ""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."" I thought DNS requests just get the domain, not the hash and not even the page reque…
The idea of that quote is that using the anchor would only scroll to that part of the page if the word "cancer" is present, and if the page uses lazy-loading then it would fire off more requests than it would if the word wasn't present. It's a bit of a stretch though.
Re: Chrome deploys deep-linking in latest build despite privacy concerns
#5The quote about DNS seems wrong to me ""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."" I thought DNS requests just get the domain, not the hash and not even the page reque…
also #fragments aren't sent to the server at all, unless this changes that (a major major change if so)
Right on. This article is bull
Re: Chrome deploys deep-linking in latest build despite privacy concerns
#6The quote about DNS seems wrong to me ""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."" I thought DNS requests just get the domain, not the hash and not even the page reque…
The idea of that quote is that using the anchor would only scroll to that part of the page if the word "cancer" is present, and if the page uses lazy-loading then it would fire off more requests than it would if the word wasn't present. It's a bit of a stretch though.
[deleted]
Re: Chrome deploys deep-linking in latest build despite privacy concerns
#7The article says the folks at Google have this short docs to address the concerns:
Scroll-to-text Fragment Navigation - Security Issues
https://docs.google.com/document/d/1YHcl1-vE_ZnZ0kL2almeikAj...
Re: Chrome deploys deep-linking in latest build despite privacy concerns
#8[deleted]
Re: Chrome deploys deep-linking in latest build despite privacy concerns
#9The quote about DNS seems wrong to me ""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."" I thought DNS requests just get the domain, not the hash and not even the page reque…
Kind of an edge case privacy issue, IMO.
Imagine if the page has 10 parts. Part 1 has an image reference hosted on part1.imagehost.xyz, but loaded lazily. Each part has something analogous, an image hosted on a different domain, but loaded lazily (so, no requests before that part of the page is visible).
If you open the page and read from the top, the browser will open with part 1, Javascript will fire and tell the browser to load part1.imagehost.xyz/image1.jpg, causing a DNS lookup, HTTP(S) connection, and a request. And so on for each part (interestingly this way you can do a timing to see how fast the user is scrolling past each part).
But if the browser directly loads part 8 (the part with cancer in the example), and the Javascript only asks to load part8.imagehost.xyz/image8.jpg, the fact that the browser only asks the DNS for this hostname will reveal to the DNS admin that the reader followed a link straight there.
But if it's some health portal under the evil company's control, it seems like it'd be easier to write Javascript to fire an event to do server-side logging/send an email alert to HR if someone spends a lot of time reading the cancer section...
Re: Chrome deploys deep-linking in latest build despite privacy concerns
#10The quote about DNS seems wrong to me ""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."" I thought DNS requests just get the domain, not the hash and not even the page reque…
also #fragments aren't sent to the server at all, unless this changes that (a major major change if so)
[deleted]