Oh Vim, you have been a constant in my life, but try as I might, I cannot love you the way others have. You demand incantations, arcane and obtuse, and I'll have no more of it. I'm in love with another editor. Its name is Helix. We're getting married. Goodbye, vim.

tldr: This site lynndotpy.xyz is now hosted at lynndotpy.dev, because (1) .xyz domains are associated with spam, and (2) .dev domains are trendy!!

tldr: I need a USB mouse wiggler and I want to make it myself. I used a spare Adafruit Neopixel Trinkey with CircuitPython to prototype a simple mouse wiggler, which can be enabled/disabled with a touch. Handling "wiggling" state and input required some debouncing code, which was the most complicated part. The whole code.py script is available at the end.

This is a prototype-- I've had a hankering to learn embedded rust, and this is how I made a quick prototype with CircuitPython. A picture and comments are on my Mastodon.

I was searching for hits on an CreditKarma.com error-phrase "It looks like we're having some trouble accessing your Credit Karma account" when I found a result at https://www.middlesex.mass.edu/templateinframes/?Site=Help&Url=https://lrmdz.bartikus.site.

Look at the structure of this URL! You can put https://www.middlesex.mass.edu/templateinframes/?Site=Help&Url={ANYTHING YOU WANT}, and in this case, it looks like bartikus.site is using the legitimacy of Middlesex Massachusetts to host a CreditKarma phishing link.

This is similar to how scam sites abuse improperly-configured internal search engines to hit Google's frontpage.

Generally speaking, it's best to avoid letting arbitrary people fill out an iFrame on your website. To prove this point, I'm sending this webpage to Middlesex Community College within an iframe on their own site. One could easily replace my post with a URL to malware, pornography, etc.

Update 2024-July-17th: It appears that Middlesex has recently stopped allowing this iFrame manipulation! I made this post after being unable to reach them in any other capacity-- I guess this post is what finally got through.

Super short TLDR: I looked at three barcode-scanning boycott apps. "Boycat" and "Boycott for Peace" have reasonable network traces, but loading images exposes your IP to third parties. "No Thanks" has no Privacy Policy, falsely claims to collect no data, and makes numerous unnecessary calls to Facebook and Google.

Longer TLDR:

The iOS versions of these apps were analyzed in February.

"Boycat" and "Boycott for Peace" expose your IPs to some third parties to load images, and have similar features. Both are good and easy to recommend, but Boycat has an overly-broad Privacy Policy and a Terms of Service which includes Arbitration.

Boycat has aims to be a more general purpose boycotting platform, whereas Boycott for Peace is focused singularly on the BDS movement.

"No Thanks" makes many tracking calls to Facebook and Google and has integrated advertisements. It offers no compelling features over Boycat or Boycott for Peace, and cannot be recommended. Further, it does not have a working link to a Privacy Policy, and falsely claims "No Data Collected" on the iOS app store.

Boycotting a corporation is hard to do when there are so many corporations to keep track of.

There are a number of apps coming out lately which promise to make it easier to participate in BDS boycotts. Thirty-seven US states have passed anti-BDS laws alongside Canada, France, Germany, Spain, and the UK. Given the US Government's long history of using apps to spy, such as with the U.S. Military buying location data from Muslim prayer and Quran apps,

I'm one of those big skeptical privacy freaks. Apps, either through malice or unawareness, can leak huge amounts of data that can later be used to surveil and suppress people.

So I decided to take a look into these apps. I used mitmproxy to inspect and modify traffic between the app and the server for this analysis, but I did not touch the server or internal code in any other way.