Transparently injects (even) more Trump into your online experience
(full size images here)
Technology was orginally created for this project...
http://tegabrain.com/Selected-Work/Eccentric-Engineering
...and code is a fork of this project...
https://github.com/bigjosh/plantWAP
Runs on either...
- Raspberry Pi 3
- Raspberry Pi 2 with suitable Wifi adapter
This is the easiest way to get running, but requres a very large (1+GB) download.
You will need a blank 2GB+ SD card.
- Download latest trumpWAP release image under the
releases
tab above - Burn it onto the SD card like this
- Insert the card into the Pi and turn it on!
- (Optional) Expand the file system so you have more room for logs and generated images.
This assumes you already have a Pi running with the latest Raspberian running on it. I used Jessie.
We will only need to download and install the extra stuff that makes a Pi into a trumpWAP. (this can take a long time depending on internet connection)
sudo git clone https://github.com/bigjosh/trumpwap.git
cd trumpwap
sudo ./setup.sh
You can update to the latest version without rinstalling via update
...
cd trumpwap
sudo git pull
sudo ./update.sh
- Change the default password using
raspi-config
- Installed Weaved.com so so you can access remotely
After it boots, connect to the Wifi trumpWAP
network.
To test, you can pull up this image, which should look like trump and not two loosers.
- Only replaces images on
http
connections. Does nothing to images loaded onhttps
connections. - Only replaces images with URL file names that end in standard image extentions (ie.
png
,gif
,jpg
, etc). Does nothing to images that do not follow these naming conventions even if they have an image MIME type. - If things get too busy (currently set at 20 outstanding requests), then we stop injecting and pass the orginal images unaltered.
Note that some or all of these limitations could likely be mitigated or cured with more effort.
You can replace the image links in urls.txt
with anything you want (does not need to be trumps).
- If you use small or low res images, they will look crappy when they are scaled to repalce large source images
- If you use large and hi res images, they will take longer to resize so there will be a longer delay the first time an image is injected at a given size
After you change the images, you need to clear the cache and restart the server by entering...
sudo rm /var/www/html/images/*
sudo squid3 -k reconfigure
- A standard
hostapd
manages the Wifi access point - An
iptables
redirect sends allhttp
connections to a localsquid3
server - The
squid3
server is set up to run as atransparent
proxy on port 3128. It runs the url_rewrite_program/etc/sqrewrite.sh
on each incoming request. - The
sqrewrite.sh
script checks the file extention on each request to see if it ends in a common image extention. If not, it passes the request unchanged. - If the request was for an image, then we go out and grab the requested image using
wget
and save it to a temp file. - We use
graphics-magick
to inspect the downloaded image and get the dimensions. - We randomly pick one of the repalcement images in
/etc/trumpwap/images
to inject. - We again use
graphics-magick
to resize the selected repalcement to match the original and save the result in/var/www/html/images
with a file name based on which repalcement images we used and the size. Note that this step can cause some delay if the replacement image is large, but hopefully we only need to resize once per replacement image at a given size. - The script returns the path to the newly generated resized replacement image on the local
appache2
http server on port 81. squid3
returns the injected image to the browser!
Did you know that every http request from Chome running on Android is proxied though Google servers? Me neither! All documented here...
https://developer.chrome.com/multidevice/data-compression-for-isps
...except the cannary does not work as documented!!!
To try and cure this, we intercept the cannary URL with these lines in the rewrite script...
if [[ $url == "http://check.googlezip.net/connect" ]]; then
echo "$(date +%H%M%S): Chrome DCP came a knocking and we sent them a walking"
echo "OK url=\"http://192.168.42.1:81/dont_proxy_me\""
else
ICAP would let us mange responses rather than just requests. Then we could...
- Check the MIME type on responses to see if we are dealing with an image. This is much more acurate that checking the filename extention on the request like we do now.
- Deeply modify links in HTML pages to change
https:
links into special man-in-the-middlehttp:
links. This would be particularly helpful on the NYTIMES mobile site which (for unfathomable reasons) serves pages as http but the static images inside those pages are https.
This would let us completely get rid of squid and appache. It could be more efficient becuase we could detect images repsonses from just the http
header, and then only download enough of an image to get it dimensions from the header. That is all the info we'd need to inject the new image slip-stream into the response.
Graphics Magick is great, but we could likely write a resizer along the lines of epeg
that could be an order of magnatude faster, especially if we used the new turbo-lib-jpeg stuff.
Basically rewrite the google DCP server to replace images rather tha compress them. This could end up being faster than direct access.