Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#4548 closed Enhancement (fixed)

Non-local stylesheets and js

Reported by: Harry Owned by:
Priority: Low Milestone: 2.50
Component: Web Client Version: 2.41
Severity: Minor Keywords:
Cc: transmission@…

Description

Why are the stylesheets and js from GoogleAPIs not hosted locally? Is there a licensing issue or something? Hosting it locally would prevent any sort of privacy issues, and avoid loading with places that may block Google services (and speed up loading times if connected locally to the webclient).

GET /ajax/libs/jqueryui/1.8.16/jquery-ui.min.js HTTP/1.1 Host: ajax.googleapis.com Referer: http://mywebclient:5555/transmission/web/

If there's not some issue with hosting the content locally, may it please be done?

Thanks.

Change History (11)

comment:1 Changed 10 years ago by jordan

  • My guess is that using the CDN will speed up loading times, since many people will already have jquery cached from that location.
  • What is the privacy issue that you're describing?
  • Also, after searching for "google cdn blocked", I don't see any major issues that people are having with a blocked CDN.

I agree that it's a tradeoff but so far I think it's worthwhile. Do you have more information about the privacy & blocking complaints?

comment:2 Changed 10 years ago by Harry

1) Maybe. They aren't that large though.

2) The main privacy issue I see is the referer header, and I don't think there's any way to prevent sending that without changing browser settings or hosting it on a different host (on the same host as the webclient, ideally). Not that Google would even care, but I think there are some people who would much rather not have their access log saved by Google if possible -- just tinfoil hat stuff mostly ("what if the government subpoenaed Google for all */transmission/web/* referrals?"), and such.

3) Theoretically mostly. Some countries have banned access to Google IPs in the past such as Iran.

Forgot to mention, there's also no <noscript> tags on the webclient as far as I can see. Shouldn't hurt anything to have a small <noscript>this requires js!</noscript> somewhere, though most people would figure out themselves why it isn't loading.

comment:3 follow-up: Changed 10 years ago by pathetic_loser

As for me, loading external stuff in web interfaces is not welcome.
1) There are more DNS requests and connections and they have to travel over external network.
2) Isolated local installations will not work. But I have a little idea why it should be wrong to run torrent tracker and clients in, say, isolated/private LAN environment and using T to perform some of operations as it's lightweight and fits servers well. What's wrong in distributing large files via torrent in LANs? It's very nice for content mirroring and such. Torrent allows it and there is even LPD extension to make it easier within same broadcast domain.
3) Your web face seems to use HTTPS! Which is slow under some circumstances. SSL sessions setup is not a very fast operation.
4) I do not want to inform external resources (Google or whoever else) each time I'm accessing web interface (of anything!) that I'm actually doing so. This looks bad from privacy point of view. Ironically you use HTTPS to compromise user's privacy. Weird enough.

In short, asking external resources when there is local web server seems to be very odd idea. What is the benefit of doing so?

comment:4 in reply to: ↑ 3 ; follow-up: Changed 10 years ago by jordan

Replying to pathetic_loser:

asking external resources when there is local web server seems to be very odd idea. What is the benefit of doing so?

http://encosia.com/6953-reasons-why-i-still-let-google-host-jquery-for-me/

comment:5 Changed 10 years ago by jordan

  • Resolution set to worksforme
  • Status changed from new to closed

comment:6 in reply to: ↑ 4 Changed 10 years ago by Harry

  • Resolution worksforme deleted
  • Status changed from closed to reopened

Replying to jordan:

http://encosia.com/6953-reasons-why-i-still-let-google-host-jquery-for-me/

That article deals with public-facing sites. I agree 100% about a public-facing site should use Google's CDN; but this is a private webinterface, so all content related to it should remain private. If I am explaining it properly...

comment:7 Changed 10 years ago by jordan

  • Resolution set to worksforme
  • Status changed from reopened to closed

Okay, I gave this a try to see what it would be like changing those three files to be served by transmission rather than Google's CDN. The next problem is that jquery-ui's CSS has about 20 links to png files. We would need to serve up all of those as well.

This is doable, but it seems very clumsy to bundle all of these things with Transmission, and less efficient than using a cached CDN.

comment:8 Changed 10 years ago by wb4x

  • Resolution worksforme deleted
  • Status changed from closed to reopened

Are you serious about efficiency? My server is much closer to me than Google's one at the moment. I have some ~20ms ping to google and some ~1ms ping to my own server in the same 100M lan. I do not see how their CDN closer to me that my Transmission client in the same segment of 100M Ethernet lan.

As for me, I'm really starting to hate this f...g Google and those Google-inclined. Sure, I should report to Google each time I want to access webface and of course I should not be able to access my very own server's web face located in the very same subnet when internet connection goes down for any reason. It's so convenient and preserves my privacy at high level, sure.

comment:9 Changed 10 years ago by jordan

  • Milestone changed from None Set to 2.50

Yes, I am serious about efficiency. A cached file isn't going to require any network traffic at all.

Thinking about this ticket some more, though, I've got to agree with the people commenting in this ticket that these files should be bundled. It's not as convenient for packaging, but it is marginally more private than loading these files from an external CDN, and the Transmission team tries to err on the side of respecting users' privacy.

comment:10 Changed 10 years ago by jordan

  • Resolution set to fixed
  • Status changed from reopened to closed

fixed in r12983 and r12984.

comment:11 Changed 10 years ago by jordan

Ticket #4584 has been closed as a duplicate of this ticket.

Note: See TracTickets for help on using tickets.