4 ms·

This and the other stuff described in these discussions relies on Javascript, CSS or certain HTTP headers. If the results are requested with a simpler HTTP cli

by 3xblah 7y ago

This and the other stuff described in these discussions relies on Javascript, CSS or certain HTTP headers. If the results are requested with a simpler HTTP client that does not automatically execute Javascript or CSS, where we can control te HTTP headers, then these manipulations can easily be sidestepped. This is not "blocking". It is using a client that does not process JS or CSS, where we can easily control the headers sent. This can be done, e.g., with openssl s_client, obsd nc, socat, etc. They are probably sending different html+css+js based on user-agent. They have been doing that for many years. The difference this time is people are objecting to the look of what they are sending.

deleted 7y ago
[deleted]
svnpenn 7y ago
Blocking 3rd-party scripts, 1st-party scripts and even inline scripts doesnt do what you say it does. It not as easy as you say it is, theyre using server side scripts to mangle the URLs.
- deleted 7y ago
  [deleted]
- userbinator 7y ago
  A filtering proxy can still fix the results by substituting the real URLs, since they are still unmolested in the href= attribute of the anchor tags.
  - tempodox 7y ago
    I'd still rather vote with my feet than putting effort into repairing what Google fucked up. That would seem like a pointless arms race to me.
  - 3xblah 7y ago
    Long live privoxy. However, I wonder how privoxy users handle TLS. I use localhost proxies to decrypt TLS before it reaches destination programs as well as encrypt outgoing plaintext HTTP traffic from non-TLS enabled programs. Using proxies allows me to edit incoming and outgoing traffic where needed. From the privoxy FAQ: 4.15. How can Privoxy filter Secure (HTTPS) URLs? Since secure HTTP connections are encrypted SSL sessions between your browser and the secure site, and are meant to be reliably secure, there is little that Privoxy can do but hand the raw gibberish data though from one end to the other unprocessed. The only exception to this is blocking by host patterns, as the client needs to tell Privoxy the name of the remote server, so that Privoxy can establish the connection. If that name matches a host-only pattern, the connection will be blocked. As far as ad blocking is concerned, this is less of a restriction than it may seem, since ad sources are often identifiable by the host name, and often the banners to be placed in an encrypted page come unencrypted nonetheless for efficiency reasons, which exposes them to the full power of Privoxy's ad blocking. "Content cookies" (those that are embedded in the actual HTML or JS page content, see filter{content-cookies}), in an SSL transaction will be impossible to block under these conditions. Fortunately, this does not seem to be a very common scenario since most cookies come by traditional means.
    - nonbirithm 7y ago
      > As far as ad blocking is concerned, this is less of a restriction than it may seem, since ad sources are often identifiable by the host name Except if you use YouTube, which is a pretty significant service but impossible to use domain-based adblock like pi-hole with since both ads and content are served through the same Google domain. If you use the YouTube for Android app that means you have to sit through ads. The alternative is something like invidious[0], but last time I tried it was impossible to seek videos more than half an hour because the seek bar shares its space with the player controls so it ends up occupying only ~15% of the viewport. That or waiting for Firefox Nightly to support WebExtensions. [0] https://invidio.us https://invidio.us
      - 3xblah 7y ago
        "... but impossible to use domain-based adblock like pi-hole since both ads and content are served through the same Google domain." However, ads and video are not served through the same Google domain. Further, the ads are not served unless Javascript is enabled. As such, aside from user comments, it is easy to retrieve the non-video content without retrieving the ads. Just use an HTTP client that ignores Javascript. Javascript is not needed to view video from the domains that serve the video.

by 3xblah 7y ago

deleted 7y ago

[deleted]

svnpenn 7y ago

Blocking 3rd-party scripts, 1st-party scripts and even inline scripts doesnt do what you say it does. It not as easy as you say it is, theyre using server side scripts to mangle the URLs.

deleted 7y ago
[deleted]
userbinator 7y ago
A filtering proxy can still fix the results by substituting the real URLs, since they are still unmolested in the href= attribute of the anchor tags.
- tempodox 7y ago
  I'd still rather vote with my feet than putting effort into repairing what Google fucked up. That would seem like a pointless arms race to me.
- 3xblah 7y ago
  Long live privoxy. However, I wonder how privoxy users handle TLS. I use localhost proxies to decrypt TLS before it reaches destination programs as well as encrypt outgoing plaintext HTTP traffic from non-TLS enabled programs. Using proxies allows me to edit incoming and outgoing traffic where needed. From the privoxy FAQ: 4.15. How can Privoxy filter Secure (HTTPS) URLs? Since secure HTTP connections are encrypted SSL sessions between your browser and the secure site, and are meant to be reliably secure, there is little that Privoxy can do but hand the raw gibberish data though from one end to the other unprocessed. The only exception to this is blocking by host patterns, as the client needs to tell Privoxy the name of the remote server, so that Privoxy can establish the connection. If that name matches a host-only pattern, the connection will be blocked. As far as ad blocking is concerned, this is less of a restriction than it may seem, since ad sources are often identifiable by the host name, and often the banners to be placed in an encrypted page come unencrypted nonetheless for efficiency reasons, which exposes them to the full power of Privoxy's ad blocking. "Content cookies" (those that are embedded in the actual HTML or JS page content, see filter{content-cookies}), in an SSL transaction will be impossible to block under these conditions. Fortunately, this does not seem to be a very common scenario since most cookies come by traditional means.
  - nonbirithm 7y ago
    > As far as ad blocking is concerned, this is less of a restriction than it may seem, since ad sources are often identifiable by the host name Except if you use YouTube, which is a pretty significant service but impossible to use domain-based adblock like pi-hole with since both ads and content are served through the same Google domain. If you use the YouTube for Android app that means you have to sit through ads. The alternative is something like invidious[0], but last time I tried it was impossible to seek videos more than half an hour because the seek bar shares its space with the player controls so it ends up occupying only ~15% of the viewport. That or waiting for Firefox Nightly to support WebExtensions. [0] https://invidio.us https://invidio.us
    - 3xblah 7y ago
      "... but impossible to use domain-based adblock like pi-hole since both ads and content are served through the same Google domain." However, ads and video are not served through the same Google domain. Further, the ads are not served unless Javascript is enabled. As such, aside from user comments, it is easy to retrieve the non-video content without retrieving the ads. Just use an HTTP client that ignores Javascript. Javascript is not needed to view video from the domains that serve the video.