3rd Party Scripts For Tag Completion

I'd recently noticed that tag completion stopped working, and checked my uMatrix settings for this domain to see that scripts from JQuery.com were now attempting to be loaded.

Making site functionality depend on 3rd party ECMAScripts is quite bothersome and undesirable. Even assuming that no JQuery script sends any data back on what tags are being search, or other information (for now), just issuing GET requests for the ECMAScript itself is an obvious privacy concern: it is not any of JQuery.com's business what the IP addresses of Danbooru users are, or even that Danbooru uses its library at all. And then the code itself is outside of Danbooru's control, subject to change at any time. Both of these concerns are even worse when talking about an extremely popular 3rd party source like JQuery, but in terms of tracking threat and attractiveness as a target for malicious injection.

Couldn't the relevant code just be served from Danbooru? Isn't that how it used to work anyway?

AR said:

Even assuming that no JQuery script sends any data back on what tags are being search, or other information (for now), […]

If you search for something, the tags you searched for show up in the URL. When loading the JQuery script, the full URL is sent as referrer, so unless you prevent it, JQuery is already leaking everything you do on Danbooru: every tag search, every post you view, etc.

With uMatrix, you can prevent this information leak by enabling referrer spoofing (I always have it on because it rarely causes problems). I believe it simply replaces the full referrer URL with just the domain, so all that remains being leaked is that you’re on https://danbooru.donmai.us/.

There are probably other add-ons to achieve the same effect.

Couldn't the relevant code just be served from Danbooru? Isn't that how it used to work anyway?

Yes, that’s how it used to work.

kittey said:

If you search for something, the tags you searched for show up in the URL. When loading the JQuery script, the full URL is sent as referrer, so unless you prevent it, JQuery is already leaking everything you do on Danbooru: every tag search, every post you view, etc.

Why would this be allowed in the first place? What is the benefit of have jQuery doing the work outside of the website?

tapnek said:

Why would this be allowed in the first place? What is the benefit of have jQuery doing the work outside of the website?

jQuery doesn’t do any work outside of the website. It only runs in your browser. The script’s code is fetched from the jQuery webserver, though, and to do so, browsers send the current page URL along as a referrer (with some exceptions). That’s how HTTP is supposed to work.

tapnek said:

Why would this be allowed in the first place?

"Why would this be allowed in the first place?" is a question that any reasonable person is going to be asking themselves a lot as they learn about how many modern websites work. This worrisome change is the first occasion I've had to be asking it about Danbooru, tho.

AR said:

"Why would this be allowed in the first place?" is a question that any reasonable person is going to be asking themselves a lot as they learn about how many modern websites work. This worrisome change is the first occasion I've had to be asking it about Danbooru, tho.

I wouldn't mind if it's a website like Google or Facebook, but Danbooru is much smaller than them and I thought it would be better.

kittey said:

jQuery doesn’t do any work outside of the website. It only runs in your browser. The script’s code is fetched from the jQuery webserver, though, and to do so, browsers send the current page URL along as a referrer (with some exceptions). That’s how HTTP is supposed to work.

I understand now. Thinking about it, what sniffer is going to care about the specific interests of the users here?

tapnek said:

Thinking about it, what sniffer is going to care about the specific interests of the users here?

Any sniffer who figures out how to make money with it. That’s how companies like Google and Facebook work. “Nobody’s interested in what I’m doing” is a common misconception. ;)

kittey said:

Any sniffer who figures out how to make money with it. That’s how companies like Google and Facebook work. “Nobody’s interested in what I’m doing” is a common misconception. ;)

More like how porn spam ads work.

kittey said:

Any sniffer who figures out how to make money with it. That’s how companies like Google and Facebook work. “Nobody’s interested in what I’m doing” is a common misconception. ;)

Man, I'd really like to know what advertisers are interested in Danbooru users in particular. What do you sell to someone whose searches are for things like sitting_in_tree bottomless, minigirl tempura, oldschool scenery, male_focus applying_makeup, etc?

Opened issue #3663 for this.

The main benefit of using an external CDN is better caching. New visitors to Danbooru won't have to download jQuery if they recently visited some other site that already loaded the same version of jQuery from https://code.jquery.com.

Danbooru is already using subresource integrity to ensure the file isn't tampered with. If the file is modified then the browser will refuse to execute it.

As far as "what if malicious code somehow gets in anyway and sends my search data back", that could be mitigated with a Content Security Policy. This would likely cause problems with userscripts though.

The referrer leakage issue can be fixed by setting a referrer policy. This would also prevent referrers being leaked to source sites when clicking source links on posts or profile links on artists.

And note that since the library is cached by your browser, you're not leaking your IP and/or referrer on every pageview. You're leaking it once, when the library is initially downloaded, typically when loading the front page. As long as the library stays cached by your browser, it won't be requested again.

Well, today I learned about subresource integrity. That's good. I hope most sites actually use it.

I'm not directly worried about my own privacy, as I already have the normal counter-measures in place. Hence how I noticed the shift to 3rd party scripts when they stopped working. But the mere fact of having privacy-oriented settings stands out, so for the sake of degrading the use of tracking in general, and to more easily hide in the crowd myself, I try to push for greater privacy-by-default, and against normalization of needing to allow 3rd party requests for site functionality.

(I don't mind Google analytics much because it can be easily blocked without affecting site functionality, unlike, say, Google API references.)

kittey said:

With uMatrix, you can prevent this information leak by enabling referrer spoofing (I always have it on because it rarely causes problems). I believe it simply replaces the full referrer URL with just the domain, so all that remains being leaked is that you’re on https://danbooru.donmai.us/.

Danbooru now sets the "strict-origin-when-cross-origin" referrer policy, which effectively does this (spoofs the referrer as https://danbooru.donmai.us/ for all cross-origin requests).

There is a "same-origin" policy that's even stricter (it doesn't send the referrer at all for cross-origin requests), but it might trigger the anti-hotlinking protection on raikou1/raikou2, so I'm not sure if we could use it.