Version: 0.4
Gitlab Issue Listing Script (GILS) is a php front-end to the Gitlab API. It's intended as a means to work around Gitlabs awful SEO
Much like my original JIRA implementation (JILS) it provides a simple HTML view of information - it's intended as a read-only interface rather than one accepting input.
RemoveAMP is a userscript for Greasemonkey/Tampermonkey designed to pull in a short snippet of javascript that will attempt to detect Accelerated Mobile Pages when they load, and navigate away from them to the fully functional canonical URLs. If the publisher hasn't specified the canonical, a DuckDuckGo search link will be injected into the page to help you find it.
See the Project README and FKAMP-1 for more information on why I consider this desirable.
As of April 2022, issue tracking can be found here
Version: 0.3
Gitlab Issue Listing Script (GILS) is a php front-end to the Gitlab API. It's intended as a means to work around Gitlabs awful SEO
Much like my original JIRA implementation (JILS) it provides a simple HTML view of information - it's intended as a read-only interface rather than one accepting input.
Version: 0.4
Privacy Friendly Analytics is a glorified hit-counter - it's designed to capture details that are useful for improving delivery without capturing user-specific information.
The original design/rationale can be found in the post Designing Privacy Friendly Analytics
I recently tweeted a short thread having noticed an unexpected domain in my analytic system's "bad domains" list.
A "bad" domain is one that's serving my content, but is not one of my domains.
For example, if you were to download this page onto a webserver serving foo.example.com, when someone viewed your copy of the page, I'd see foo.example.com in my bad domains list. The same would be true if you instead configured a CDN (like Cloudflare) to serve my content under your name etc.
Ordinarily the list alerts me when I've made a mistake in configuration somewhere, as well as helping keep track of which Tor2Web services are active.
What I saw on that Saturday was somewhat different:
I'm censoring the exact domain name as identifying it in full doesn't really serve any useful purpose (although this post will use a fuller name than in my earlier tweet: part of the name is publicly discoverable anyway).
Someone had viewed a page containing my analytics at the url https://[subdomain].profound.cellebrite.cloud/webfiles/on/io/e26whn2524322mkxb3cbyk27ev2ihhq2biz35hty7gzgsyrwrygq27yd.onion/posts/blog/116-republished-freedom4all/C38EB530D1FD2C0105D250C1AB5E4319.OM20220324085844.html
This is interesting for a few reasons
C38EB530D1FD2C0105D250C1AB5E4319.OM20220324085844.html doesn't fit any naming convention I've ever usedYou might have heard the name Cellebrite before: they've been in the news a number of times, with topics including suggestions that they'd sold their services to Russia and Belarus, the assistance they provided in prosecuting the tragic Henry Borel case, and claims that they helped the FBI crack the phone of the San Bernardino shooter.
More recently, Moxie Marlinspike highlighted vulnerabilities in Cellebrite's UFED product.
I already knew of the company, not least because they popped up in the Bitfi stuff a couple of years back.
With a background like that, seeing their name anywhere near my stuff couldn't but provoke a bit of curiosity.
I reported my findings to Cellebrite (who have resolved the issue) and we'll look at their response towards the end of this post. I first want to explore the techniques used to highlight how just a little bit of meta-data can guide the discovery of so much more.
Version: 0.3
Privacy Friendly Analytics is a glorified hit-counter - it's designed to capture details that are useful for improving delivery without capturing user-specific information.
The original design/rationale can be found in the post Designing Privacy Friendly Analytics
Version: 0.2
Privacy Friendly Analytics is a glorified hit-counter - it's designed to capture details that are useful for improving delivery without capturing user-specific information.
The original design/rationale can be found in the post Designing Privacy Friendly Analytics
Version: 0.3
Ecowitt Listener is a small Flask application (within a docker image) designed to accept writes from Ecowitt weather stations and write data onwards to other destinations (though primarily InfluxDB)
I recently acquired an EcoWitt weather station.
It comes as a kit, consisting of an EcoWitt GW110 Gateway and an EcoWitt WS69AN 7-in-1 Weather station.
It's advertised as being able to write into WeatherUnderground as well as EcoWitt's own service, so I figured I'd probably be able to do something to catch its writes and get them into InfluxDB.
The listing doesn't make it clear, but it actually supports configuring "custom" weather services, so this proved to be extremely straight forward so was largely just a case of building something to receive and parse the writes.
This post details how I did that and, in theory, how you can too (in principle, it should work with any of their weather stations)
Version: 0.2
Ecowitt Listener is a small Flask application (within a docker image) designed to accept writes from Ecowitt weather stations and write data onwards to other destinations (though primarily InfluxDB)
