How to find out if your phone is spying on you

<tinfoil-hat>

I browse 9gag a lot during my commute. Sitting shoulder-to-shoulder with my fellow commuters I find it uncomfortable to do something on my laptop, and at least in the mornings I’m not awake enough yet to properly enjoy a book or audiobook. So instead, I turn to 9gag for my cheap entertainment. As such, I see quite a lot of ads.

Over the past few months I’ve managed to convince myself somehow that the ads that I’m seeing are targeting things that I’ve only ever mentioned verbally, but never digitally. It’s just extremely suspicious to see an ad for one particular brand the day after you’ve spoken about it to someone. This kept happening to me, so I thought of a way to try and ‘prove’ that my phone is indeed listening in. My wife and I had a running joke for a while where we’d shout odd terms (“ARNE JACOBSEN CHAIR!”, “NISSAN MICRA!”) at my phone to see if ads for them would show up. (No for the Arne Jacobsen chair, yes for the Nissan Micra, but cars in general are already a natural search term for me and there’s a digital trail showing that I like cars, so no solid evidence there).

To take it one step further I devised an experiment. For a few days my wife and I brainstormed about topics that we would never ever look up naturally; topics that are so far removed from our daily (digital) lives that it would be very unlikely for us to see targeted ads for them. We tried to focus on popular topics that people or companies would actually buy ads for. All this was done offline, on a small piece of paper, and to the best of my knowledge neither of us ever uttered one of these topics out loud or typed it in digitally until the experiment was over.

While we were devising the list of topics I took screenshots of all the ads I saw on 9gag, as well as a few on Facebook and in my browser. The idea is to compare these to the ads I got served after uttering each of these topics out loud.

With the list of topics finished, rather than manually conversating through them in the vicinity of my phone, I instead prepared an old laptop of mine with a text-to-speech script which I ran overnight. I downloaded PyTTSx, made sure that it worked, then disconnected the laptop, which had a clean Windows installation with no personal information about myself, from the network, and uninstalled the network drivers. Then I wrote a Python script to run some plausible conversations about the topics we had written down on paper thought the TTS engine, and set it to loop. I had to listen through each topic several times to make small adjustments to the spelling because the TTS didn’t quite pronounce all the words right unless you spelled it slightly wrong. I added in a few voices and a few speeds and ran the script overnight with my phone charging right next to the laptop, far far away from the bedroom. Because listening to a computer having a fake conversation about topics you couldn’t possibly be less interested in does get boring after a while.

At this point the topics did exist digitally, but only on a laptop that was disconnected from the internet. I continued my daily routines as usual and again took screenshots of all the ads that I saw. I kept this up for 2 days before I got bored of taking screenshots, after which I categorized all the ads I saw into one or two categories and tallied up the results. 

The Topic column contains whether the category would be something I’d expect to see naturally anyway, or one of the “highly unlikely taboo topics” that I would otherwise never search for or would never even come up in my daily life. The rows highlighted in yellow are where the taboo topics overlap with the ads I saw, and the rows highlighted in red are the particularly suspicious rows of topics of which I suddenly got served a lot more ads after running the taboo topic script. There were also a whole bunch of taboo topics that I never saw ads for, presumably because no company paid for ads for those topics, or because I’m a crazy tinfoil-hat guy who’s just a bit too paranoid.

I’ll try and be generous and explain away both the medical category and the pets category. I was already served one ad in the medical category before running the script (which uttered some new and much more.. un-science-y medical keywords), so a slight increase is not entirely unbelievable. The same goes for pets: although the keywords in the taboo script were very heavily focused on dogs (whereas my wife and I are very much of the cat persuasion), we do have a pet and it’s not unlikely that this information could have crept up in our digital life during the course of the experiment, outside of the TTS script.

Then there’s the third red category that shows a sharp increase, for which I just can’t find a reasonable explanation: loans. The ads in this category were for 1. credit ratings, 2. leasing cars, and 3. short term loans. I’ve been employed pretty much continuously over the past 12 years, have never searched for or had a loan (other than my mortgage, which is a very specific loan category that hasn’t popped up either before or after the experiment). The TTS script contained several passages about wanting to buy or build (expensive) DIY things as well as the actual term “pay day loan”, and some other words that could perhaps imply increased gullibility to these kind of ads. When I was categorizing the ads I saw a very clear distinction between ads that focused on investing capital (category ‘Investing’ in the image) and ads that focused on how to loan things or improve one’s ability to loan things.

I can think of several explanations of why the ads changed after the experiment:

  • Coincidence. Ads change over time. Maybe the loan companies just didn’t buy any (targeted) ads until in the middle of my experiment. I didn’t run the experiment anywhere near long enough to rule this out.
  • Leaks. Maybe I changed something about my online behaviour that changed the ads I was served.
  • Something on my phone or in my house is listening in. Could be the phone OS, could be an app on the phone, could be a nearby TV or PS3.

It would be possible to go one step further and intercept the network traffic coming from my phone, but I don’t think I would be able to conclusively prove anything one way or another. If the speech recognition happens client-side then I wouldn’t see any speech data over the network. Or it could be encrypted. It might be worth a try, but I suspect I won’t find anything obvious.

Is this enough evidence for me to say that my phone is definitely listening in on me? Definitely not. But this, combined with earlier incidents of ads matching conversation topics over the course of the past few months, I think is more than enough reason for me to be suspicious. It would be interesting to see other people try the same experiment. If they find the same results then we could start comparing phone OS, installed apps, other nearby electronic devices, etc.

For now, since I hardly ever speak on my phone anyway, I’ve put a little bit of blu tac over the microphones. I tested this with by calling my wife to confirm that no audio is heard on her end when I speak. If, over the course of the next few weeks, I find myself not noticing a single instance of an ad matching a conversation topic, I would consider that pretty strong proof that something on my phone is listening in. No matter the outcome, it’s probably worth a followup experiment. Time to think of new categories.. (Don’t send ideas for new categories to me, obviously! Unless it’s a handwritten letter..)

</tinfoil-hat>

Posted in Daily Life, Tech | Tagged , , , , , , | Leave a comment

Raspberry Pi controlled Lego car part 3

Things have not gone smoothly since the last post. I can’t seem to stop spending money on this..

Last time my goal was to build a two two-speed gearboxes, connected via a gear switch lever, controlled via servo motor, that will allow me to switch both gearboxes simultaneously via the Raspberry Pi . I have absolutely no reason to do this. The car will work just fine with only one gear. It just seemed like an interesting thing to do. It led to me researching some rather complicated things on Wikipedia, but given that I only have one differential and (despite what these posts might make you believe) am trying to keep it simple, I decided to go with the dual gearbox option. I had already bought extra parts for this and felt too stubborn to give up on it.

That was a few weeks ago. Here’s what I initially came up with.

The first image shows the interior: the M motor controls two mini actuators. You can see the top one, there’s a bottom one as well controlling the axis in the other direction. The second image shows both gearboxes attached. I had to give up my plan to use the servo motor almost right away, because getting the gearing right for the servo motor to shift the axis exactly 1 block left or right proved nearly impossible, and very easy to go wrong over time. In this first design I had planned to use the regular M motor with a clutch gear to make it stop when it reached the end of its travel, but due to the way I connected the gears it didn’t quite work. I also realized during building this that I couldn’t have two identical gearboxes; I had to mirror the design in order for the gear-shift actuators to select the same gear every time.

This design was way more sturdy than the one from the previous post, but still not quite study enough. Other than that there are two major problems with this design. The first is that it is just massive. Both driving axes are mounted very far away from each other, meaning I needed lots of tracks to connect the two. My prototype had completely flat tracks in-between the two axes, which resulted in a massive contact surface with our thick carpet. The prototype was geared the same way as previous ones, but simply did not have enough power to move.

The second problem is the way it shifts the gear-shift axes. Each actuator is connected to gear axle with only one point, so in order to shift gear it either performs a push or a pull motion. There’s nothing stopping the actuator mount point from shifting other than two little stoppers on the axle. This turned out to be rather weak, and they ended up getting pushed or pulled away from the bit that connects the actuator to the axle, making its range wider and wider until it just stopped working completely after a few shifts. Fail.

Last time I mentioned that the USB-to-9v cable that I bought was faulty, and that I was actually able to power both the Pi and the motors from a single USB battery pack. This turned out to be mostly true, yet ended up not helping me in any way. I bought a new USB-to-9v cable, and this time it did work correctly on my battery pack of choice I was using, a Tecknet 10000mah pack , which is very thin and easy to hide inside the Lego. Sadly I found out after getting the new USB cable that this battery pack doesn’t provide the amperage needed to power two XL motors at the same time. It just barely manages, but as soon as you put some load on it then it shuts down and doesn’t restart.

That led me into yet another unexpected quest: that of finding the perfect USB battery pack: one that has two USB connectors for input, plenty of amps on each output, and ideally allows for passthrough charging without blipping the power or requiring you to press a button after plugging/unplugging. I have spent a long time searching for a suitable battery pack on the internet and have found absolutely nothing that satifies all of these requirements. There’s plenty of powerful battery packs, even powerful battery packs that allow passthrough charging, but none of them do it without blipping the power or requiring a button push to resume. There are some boards for the Raspberry Pi that allow multiple power inputs, which I think would work for autonomous recharging. That’s yet more money to spend on this though, and makes things even more complicated, so I’m holding off on that for now.

Eventually I tore apart the previous prototype and started on a new gearbox assembly. I considered building the gearbox bit vertically, but eventually decided to go horizontal again for the sake of simplicity. I increased the length of the gearbox axles by one, which allows me to connect to the gear-shifting axle on both sides rather than on just one side, so there’s no issues any more with the axle shifting from too much pushing or pulling.

Instead of using two actuators this version can do the shifting with just one actuator, which controls the two shifting arms connected to the gearboxes. I’m using a clutch gear directly on the M-motor used for shifting (not pictured in the picture above but it connects directly to the small gear on the top right). Some bits of the shifting arm have some tolerance, so that combined with the clutch gear seems to result in quite satisfying gear shifts.

Above is a picture of the latest gearbox core in yet another prototype shell. It ended up still being quite wide because I wanted to keep it modular, so I can take apart both sidewall tracks quite easily to access the gearbox core. In the end I just piled up all the non-Lego components on top in order to test it out. There’s still plenty of space inside so my goal of having a flippable robot that willwork on both sides is quite attainable.

I found out that in the current setup the highest gear doesn’t really work for turning, most likely because there’s still a fair bit of contact area. I think I can gear it down by 1.5x/1.67x and it’ll be perfect. I also need to buy a new USB battery pack, so the final design will depend a lot on the dimensions of that. I haven’t decided yet which one. More to come much later because I’m off cycling from next week!

Still to do:

  • Fix the gearing.
  • Make it lower.
  • Get better USB battery that allows for more amps.
  • Buy UPS circuit so I can build a charging station.
  • Hook up the Raspberry Pi camera, camera motor and lights.
  • Decrease track contact surface with ground if possible.
  • Build internal compartments for the electronics and the battery.
Posted in Tech | Tagged , , , | Leave a comment

Raspberry Pi controlled Lego car part 2

Not many pictures this time, because unlike last time I’ll rant a bit this time about getting the software on the Pi working. To start off: I did something rather stupid: I updated Raspbian. It took ages to update the OS and all the packages. The Pi isn’t very fast for that. I should’ve just downloaded a new image. Here’s how I lost a lot of time.

After updating the OS my wifi stopped working. I’m using a small TP-link USB wifi , since my Raspberry Pi B+ doesn’t come with on-board wifi. I did a lot of searching on why this would suddenly stop working, and found that, only in some cases, the B+ is incapable of providing enough power to the USB ports to make my particular model of wifi adapter work. The wifi did in fact work for just a split second after booting, and I was able to ping the Pi from another PC, but it almost immediately disappeared again. This I thought was a good indication that it was indeed a power issue.

I bought a USB cable from Amazon that combines two USB plugs, one for data, one for power, into one output, for the wifi plug. I was fairly confident that this would solve my problem. First I plugged both inputs into the Pi’s USB ports, but no luck. Then I tried plugging the USB power input directly into my USB battery pack, but that didn’t work either. It did have a weird side effect, in that if I disconnect the Pi’s regular micro-USB power connector, it miraculously stays powered through the USB wifi plug. Weird, but not useful.

So I did some more digging and eventually found out that for every Pi kernel you need to manually (re)compile your wifi plug’s driver. Ugh. I got started on doing that but it took ages. I eventually managed to find a site that offered precompiled drivers and simple installation instructions. Not exactly open-source but I’m definitely not going to wait hours for the bloody thing to compile.

With the wifi fixed and the motors super-easy to control via the Python GPIO library, I got to work on getting the Pi’s camera feed to work. The Pi supposedly does full-HD video capture at decent framerates so I had high hopes of getting a nice stream going. Unrealistically high hopes, it turned out. Recording decent quality video is one thing, but streaming it in real-time with little enough delay to control a moving vehicle, that’s quite another. I had to turn down the resolution all the way back to 640×480 to get <500ms delay, but after that it’s quite usable. The uv4l raspicam package comes with a built-in server to stream video, which is actually pretty nice when playing around with it on the local network, but since my final goal is to open it up to the internet I’ll have to find something a lot more secure than that. I’ll likely set up a separate Python server to forward the video feed, or stream it from the device directly. I hope it won’t introduce too much extra delay..

On the hardware front I’m playing around with some of Sariel‘s gearboxes. I bought a set of various Lego gears on ebay since my aging Lego Technic did not have many useful parts. I built this three-speed gearbox and then figured I might as well buy the Lego Servo motor as well to play around with.

Turns out that controlling a servo motor from the Pi is a lot more difficult than controlling a regular motor. To get the servo motor to go to a pre-set position you need to use pulse width modulation with a very specific duty cycle for each position. If you get the duty cycle slightly wrong the servo will jitter around the position and move back and forth a bit. The same happens when using the Python GPIO default module, which comes PWM functionality built-in, but just can’t be real-time enough to generate a stable signal. There’s loads of jitter if you try it that way. I ended up going with RPIO, which uses Direct Memory Access to get the timings right. I played with it for hours but in the end still could only get about half out of the supposed 14 positions to select correctly. I think that’s more of a problem on my side though, and I’m probably using the wrong duty cycles or frequencies. That said, I’m totally indulging at this point because the gearbox only needed the off position and full negative and positive duty cycles, so I didn’t even need to use pulse width modulation at all. It was an interesting side track though.

Once I got the three-speed gearbox working with the servo I slapped an XL motor on to it and immediately realized that this gearbox design will never work for my tracked vehicle. As soon as I applied only a little pressure on the output wheel the servo axle would fail and start rotating. It really doesn’t stand up very well to any decent amount of torque. Time for another design. I ended with a super-simple custom design for a 2-speed gearbox that I got off the internet, but all the simple designs, the designs that I actually have the parts for to build, don’t seem to be meant to be controlled with the servo motor. I played around with this for quite some time last Sunday and eventually managed to rig up some kind of controlling arm to push and pull the middle axle of the gearbox so it can shift gears. I haven’t tested this with load, though, so I’m not sure if it’ll hold up very well in the final vehicle. But I’m a bit more confident about it than I was about the three-speed servo gearbox.

The next challenge will be to duplicate the gearbox and make a design that allows the servo to change gears in both gearboxes simultaneously. Since I’m making a vehicle with independently-controlled caterpillar tracks (but only have one servo motor) I’ll need to have one gearbox for each track.

Lastly, I got one more thing wrong in the last post, about getting power to the motors. I had bought a USB-to-9V cable , which I thought didn’t work in my USB battery pack because the battery pack was smart enough to disable the port if it detected that no power was being drawn. That assumption turned out to be completely wrong. Instead, what happened was that the cable had a very shitty USB connector and after I let go of the connector it would drop a bit and disconnect. I duct-taped it into place and it works perfectly, so I can get away with using just one USB battery pack (with two USB ports) for my vehicle. Yay!

Posted in Tech | Tagged , , , | 2 Comments

Raspberry Pi controlled Lego car part 1

So, I have a fair bit of Lego lying around from my childhood days. Not a lot of technical parts, but enough to have some fun with. I also have a Raspberry Pi lying around after a failed experiment where I tried to use it as a security camera. Why not combine the two? I figured I could build a Lego car that I can control remotely via a little server on the Raspberry Pi, which would also stream its camera feed. It seemed easy enough, especially after discovering a page that explained exactly how to make the hardware part of it work. Never did I imagine it would take this much work to get it up and running..

This post will detail the hardware iterations and setbacks I faced. The next post will go into detail about the software side of things.

So, before starting on this project, here is the list of things I thought I’d need to make this work:

Version 1

I bought the M motor starter kit and a separate M motor for my first iteration. I built a very nifty motor assembly and a very strong shell structure to house the components. Here’s how it looked like:

v1.0

It is thus that I found out that I should never overengineer before testing. While building the thing I discovered that I didn’t have the parts required to drive all six wheels, so I chose to just drive the middle wheels instead. I figured that by gearing down a bit it should be fine. Much nope. The M motors were way too weak to power the construction, which was already quite heavy from the USB battery pack, but weighed down even more because of its overengineered sturdiness. Having just the center wheels powered was also a terrible decision. Fail.

Version 2

v2.0

I built this is a test version to experiment with gear ratios and to see if in a lighter version the M motors would have enough power to drive the car. Answer: not really. I got it to go forward and backward pretty decently, but I still didn’t have the parts required to power all the wheels, so the motors were not strong enough to turn the whole thing without a steering assembly. Fail again.

So I had two options at this point. Option one was to build a rack-and-pinion steering assembly, for which I had the parts available and did end up experiment with, but in the end I wasn’t happy with its turning radius and how I’d either have to buy a servo motor or have an ‘unclean’ solution with a clutch gear to handle the stopping at the end of the wheel turning axis.

Instead, I went with option two: throw more money at it. I bought two XL motors and a crapload of caterpillar tracks. That’ll give me the power and the grip I need to build something really nice.

Version 3

..or not. It does look impressive though. Here’s a test build with the power functions battery box instead of the external 9 volt battery.

v3.0-test

At this point I was still powering the motors via a separate 9 volt battery. I figured that, since my USB battery had two USB connectors, I could use it to power the motors as well, so I ordered a USB-to-9-volt cable from Amazon. That should help me save some weight by not having to put in two batteries. Sadly, this did not go well.

USB batteries are pretty smart. So smart in fact, that they only output power if they think something’s plugged in. The USB-to-9-volt cable worked fine on a powered usb hub, but every time I’d try to hook it up between the battery and the motor controller it would simply not turn on. Crap.

I found another USB battery, which is actually a battery used for starting cars that happens to have a USB port on it. This one did always keep the power on if I plugged in the USB-to-9V cable. Good! Except it only had one USB port, so I couldn’t also power the Raspberry Pi from it. So I ended up with two USB batteries and over double the original weight..

v3.0-final

The big green thing is the car-charging battery. Even without the second battery the 3:1 gearing wasn’t quite powerful enough to rotate this monstrosity when on certain surfaces, such as medium-thick carpet. Once again, fail. And once again, I spent way too much time overengineering the construction without testing it first with its full weight.

Version 3.5

I figured I’d try to keep the next version as small and light as possible and worry about motor powering and recharging issues later. I managed to build a pretty small prototype.

v3.5-test

Now, I had one option left to avoid the use of two batteries. The big green car charger battery did, in addition to its one USB port, come with a 12V output. It’s not the 9 volts that the Lego motors need, but I did find at least one link claiming that the motors should run fine on 12 volts as well. I had previously done this as a child when connecting an old technic 9V motor to my 12V Lego train controller, which gave it quite a nice speed boost as well. I figured this would be an acceptable trick. I butchered an old power supply, cut off it’s circular connector and used it to connect up the green battery’s 12V port up to the motor connector.

To avoid any more gearing issues I added another axis, bringing the final ratio down to 9:1. The build ended up much larger than I had intended, but still smaller than v3.0. With better gear ratios and a higher voltage to the motors.

v3.5-final

You may notice the second battery sticking out at the end of this bulky thing, despite the fact that the green battery has a free USB port thanks to the makeshift 12V connector. This is because the stupid battery doesn’t let you use both outputs at once. It just turns off one or the other. Not ideal!

I’m still annoyed at this but don’t have an immediate solution. The reason I spent so much effort trying to get everything onto one battery was because I intended to build a little wall charging station, so I can drive the robot into the charging station, which will connect the charging port of the USB battery onto a USB wall socket. I gave this a try with the double-ported battery while the Raspberry Pi was connected, and sadly it resets the Pi as soon as the charging connector is plugged in. Crap times two. I haven’t tried this trick with the green battery, but that’s pointless anyway since it only lets you use one device at a time. Looks like I won’t be able to charge the thing remotely while it’s running.

V3.5 still has a whole bunch of issues. It works great in terms of motor and track performance though. It moves and turns fantastically. even loaded with two bulky batteries. The motor placement isn’t great though; they’re way too close to the ground. I need to fix that in the next version. It’s also longer and wider than it needs to be. Once I get a solution to the two-batteries issue I’ll decide on how large the next version will be. I’m also thinking about buying the servo motor and using it to power a small gearbox, but I’d also need to buy more technic gears and axles for that, and I’ve kind of already spent way more on this project than I thought I would spend..

For now though, I’ll stick with this hardware design and focus on getting the software up and running. More on that next time.

 

Posted in Tech | Tagged , | 1 Comment

New hobby project

Turns out it’s really easy to control Lego power functions motors via a Raspberry Pi. I found myself a new hobby project

2017-01-08 20.24.33

Posted in Tech | Tagged , | Leave a comment

The 9gag data mining scam

(Or: what is your <insert meme here> name? Click here to find out.)

Perhaps you’re an occasional browser of 9gag or similar sites, and have come across images like these before:

Instagram-TropicalHouse-8dc5ec

People inevitably reply in the comments section with their hilarious name. Lately I’ve seen a lot more of these images than usual, and I’m guessing it’s actually an attempt at data mining by some hacker trying to dox people. The questions on the images vary; sometimes it’s the first letter of your name, sometimes it’s the date you were born, the month you were born, the first letter of your mother’s maiden name, and so on. People who are stupid enough to reply to these images with that data eventually create a very usable data trail that can be used by hackers to impersonate them on the phone. So yeah, have fun explaining to your bank that you publicly posted all details about your life in a poorly obfuscated manner.

Posted in Tech | Leave a comment

Responsiveness and Patreon!

As you may have noticed from the blinding orange link at the top of this page, I am now on Patreon

That said, I am fully aware that this is a personal blog with personal content, but on the off chance that someone enjoys my writing and would like to support me, I thought Patreon provides quite a nice way to do that. I’m perfectly happy to never get anything from Patreon and will still continue blogging, as I have done for the past 11 years. Yes, it’s been 11 years.. Interestingly that makes this blog the longest-lasting thing/activity/venture that I have in life. With possible exception of my iPod classic, those things last forever.

Creating a Patreon page was quite interesting. It really forced me to think further than ‘It would be great if people could throw money at me for writing silly stuff like this’. I had to think about what value this blog creates, what topics are the most likely things people want to see, and what is the best way to take payment. It didn’t make sense to offer payment per blogpost, since I would forfeit my freedom to write silly things that I wouldn’t dare ask people money for. Monthly contribution seems to make more sense. I assumed that of my writings, the cycling trip day-by-day travel reports are probably the most interesting to read, so any funding I get on Patreon will likely go to the cycling cause.

As a secondary effect, every time I think about increasing public exposure of this blog I get nervous about its quality. I can’t do much about the content after it’s been written, but I can do something about the styling and user-friendliness. So yesterday I wrote some css that will hopefully make this blog a lot more mobile-friendly. It’s still nowhere near perfect, but it’ll have to do for now.

Random life thing: I’m supposed to be preparing for the upcoming cycling trip later this month but instead I’m currently experiencing quite possibly the worst cold I’ve ever had in my life. I’m feeling myself start to recover, but it’ll be a few more days until I’m back to normal. I’ve got some ideas for posts lined up but nothing written down yet. There’ll be something new here soon. Stay tuned!

(ZEST)

Posted in Tech | Leave a comment

Why I won’t be moving away from WordPress

I’ve made some time for myself to do some personal projects, and one of the things that’s been on my mind for the longest time was to move this blog away from WordPress and host it statically on S3 instead. Serving a single static html page (plus a few resource files, but not many) from S3 would be so much faster than letting the shared hosting server parse endless lines of php, most of which I don’t even want. The benefit in that aspect is clear, but in other areas it’s less obvious.

Easy of deployment is one of the issues. I’m not bothered about not being able to post by email or mobile – whenever I have something to write I’ll usually have my laptop with me. It doesn’t bother me that it won’t be WYSIWYG either (which it wouldn’t be if I write my own blog software because I don’t care about WYSIWYG). The problem is always with the software and the libraries. My software of choice for my would-be static blog is python, but I’ll inevitably end up requiring some libraries that will need to be downloaded and/or set up on each machine that I want to publish from. Knowing myself, I will forget to do this before I go on a trip and end up having to download those libraries at ultra-slow speed at some hotel in the middle of nowhere. Or I might be on a public machine, which will be even worse.

Comments are another issue. If the blog is completely static I’d have to go for a javascript-based comment service. I also have old comments that will either have to be converted to the new commenting system or else inserted into the html somehow if I want to preserve them. Again, there are solutions, but they’re hardly easier than what I have with WordPress.

Finally there’s the issue of dynamic pages: the calendar, archive and search functionality. Calendar and archive pages are pretty easily generated, but I’d either have to remove the search function or rely on an external service for that. Bleh.

The system I had in mind would be a collection of small tools:

  • A converter tool to convert a wordpress database into raw blogpost/page files (the exact format of which I would have to think about).
  • A compiler tool that reads the raw posts and writes usable html
    • Inserts content into a predefined template, I was thinking Django templates. This doesn’t have to be fast.
    • Regenerates related pages (front page, archives, calenders, category pages)
    • Converts any markdown text to html
  • An uploader tool that publishes the generated html
    • Would upload to S3, perhaps pluggable so other providers would work too.
    • Would be smart enough to recognize linked images/files and upload those too.

I’d leave the template design and making the javascript commenting system work all up to the user, since that’d be a one-off job (for me, anyway). The goal of all this is to make my life easier, but it’s an awful lot of work for an awfully small amount of easiness.. Anyway, if someone else would also be interested in using something like this (or willing to pay for something like this!) then do let me know.

 

Posted in Tech | Tagged , , | 2 Comments
← Sidebar