3 ms·
The first "attribute" is simply an HTTP header. As such it can be selected and changed by the user. The user may choose not to send a User-Agent header at all
by 3xblah 7y ago
The first "attribute" is simply an HTTP header. As such it can be selected and changed by the user. The user may choose not to send a User-Agent header at all. IME, few sites actually require a User-Agent header in order to retrieve a page. Developers sometimes try to vary page content based on this header. For example, send a certain string containing the name of a "bot" and you might get nothing. The detection occurs before any content is returned.
The rest of these "attributes" are not HTTP headers, and occurs after the resource is fetched. We do not need to give away this information in order to retrieve the resource. The fingerprinting problem arises because the software we use to do the retrieval does far more than retrieve web pages. These other attributes cannot be detected unless the software used to retrieve the web page also includes other features that process what is retrieved, including a Javascript engine that runs code straight from the internet ("browser").
Looking to the authors of a popular browser to solve the problem they themselves have created. Is it rational to expect that this is where the solution will come from?
If one is willing to make some "useability tradeoffs" then one might use a simple http client to retrieve web pages instead of a popular browser. After the pages are retrieved, then one can use a popular browser to view them if desired; the browser need not have access to the internet. This is what I do. Not to avoid "fingerprinting" but just because it is faster and more robust.
With the help of a trivial program that transforms urls into http (I wrote one), one can retrieve the text/html of web pages, without requesting all the third party advertising cruft, with any tcp client such as netcat. HTTP pipelining becomes easy, making consumption of large quantities of information more efficient -- many pages, one connection. The two programs together form an "http client" with, relative to a popular browser, or even a program like curl, very low code complexity.
Whenever I see the "fingerprinting" debate come up, I always go through the same thought experiment: For situations where "fingerprinting" is a problem, web users all use the same simple http client. All send the same minimal headers. The web must accomodate users not the other way around.
- gruez 7y ago>The first "attribute" is simply an HTTP header. As such it can be selected and changed by the user. Maybe if you have script disabled, but if you have javascript it's trivial to detect which browser you're on based on javascript implementation quirks alone. >We do not need to give away this information in order to retrieve the resource. You clearly haven't seen mandatory javascript sites.
- 3xblah 7y ago"Maybe if you have script disabled." You are making the assumption that I am using a browser to retrieve the page. I can use a simple http client with no features such as JS to retrieve the page. I have full control over what headers I send and the contents of those headers. "You clearly haven't seen mandatory javascript sites." I have seen many sites that prod the user to enable JS yet still return the same text/html even when JS is disabled. Sometimes I am only after the content of the page: text, URLs pointing to images or other resources, URLs pointing to other sites, etc. I have seen some sites where there is "no content" in the initial page fetched, with or without JS enabled. These are dummy sites, hollow shells, skeleton pages. The technique is simply misdirection. All the useful content is pulled from another site via a second request (JS triggering the request). Maybe this is a CDN. I simply read the JS or use a debugger to find this "endpoint". Then use the simple http client to request the content as usual. These dummy sites are not the majority of sites on the web, nor even the majority of sites posted to HN. The endpoints supporting these "no content", dummy sites often deliver the text with fewer or no tags, without HTML. Maybe it is JSON. This makes it easier for me to format it the way I like it. What many HN readers may perceive as a growing nuisance I believe could be a blessing in disguise. I prefer delivery of content in a more "raw" format allowing the user to process it as she pleases client-side, with the software of her choice. This leaves no room for advertising. It is more efficient and the user becomes the creative one, deciding how she wants to present the content to her own eyes.
- muxator 7y agoIs this really your day-to-day way of browsing the internet? Like if you were web scraping all the time? If so, I want to shake your hand, sir.
- 3xblah 7y agoFor commercial use of the web, things like internet banking, purchasing, etc., I use what is "recommended". The popular web browser. For non-commercial use of the web, I use what I want to use. A simple http client and/or text-only browser. My day-to-day use of the internet is almost always 100% non-commercial. I never want to use a Javascript-enabled browser for simply retrieving information from the web. For example, reading. This is non-commercial activity. For simple information retrieval, I find a large, complex, popular, recommended "browser", a single, "do-everything" program, is overkill and, counterintuitively perhaps, such browsers loaded with "features" actually limit what I can do. Using smaller, simpler "one-purpose" programs to retrieve web pages allows me more flexibiilty. I can be more productive. Using single-purpose programs, I also find the retrieval process to be more reliable and robust, not to mention more transparent. I know exactly what I am sending. Unlike the popular browsers, these programs are not fetching and running code from the internet automatically. I feel a greater sense of control.