Have you heard of Toggl? It's a time tracker that integrates with your browser and let you click click click on Google Agenda meetings, JIRA tasks, GitHub PRs and hopefully most of the tools you use, to track how much time you spent on it. I've used it since 2017 and it was a game changer: helped me reduce multitasking, produce factual invoices when billing hourly, identify what ate all the time in my day...
I'm sure there are also other alternatives out there but Toggl is the only one I have experience with.
Awesome analysis, quite instructive. I am even considering adding it to my server performance tool, as a frontend performance metric, since I guess it could be easily automated. Imagine little README badges saying "quite bloated" and "pretty good" :p
In the original U2F spec, I think there was an "answer" to this revocation issue: "enroll a second device for every origin, and keep this one in a safe". This way you can still connect even if you lose the first one.
Thanks for the detailed post. The rogue word seems to be a bit too strong, as I totally understand how GitHub generated the cert thanks to Let's Encrypt. The surprising bit is that when granting them the right to handle all internet traffic for the given domain (back in 2014), I wasn't expecting them to use it to generate certificates.
Then Let's Encrypt was released to the public (yeah), and today I am happy that GitHub generated this cert. However, I was surprised to see it was generated "in my back", without any kind of notice and no public documentation of the feature.
There is no huge problem, just an interrogation over how this happened since the UI doesn't allow it and the documentation states this is not possible.
Actually this was exactly what happened and surprised me. I was moving my blog out of GitHub Pages to a self-hosted solution, and it's only after switching DNS and generating the cert for my own server that I noticed that GH Pages was ALSO serving the old version of the blog over HTTPS.
I didn't know about LE revocation mechanism at the time.
I mention CAA DNS records in the end of the post, but unfortunately the last time I checked my registrar did not offer the possibility of creating these records... :(
Oh Dear! looks really interesting (though I won't pay for monitoring my personal blog).
I am not sure I fully understand your HTTP-only remark, since how the communication is made (HTTP-only, HTTPS, IMAP, etc.) is not related on how the certificate is generated (which implies CT).
To me it felt rogue since it had been generated without me knowing nor expecting it, whereas I expect CloudFlare to do it. This is not an official feature of GitHub... But I understand the word may be too strong.
For CAA I would love to, but my registrar still doesn't allow me to create these kind of records :/
There is a slight issue with the provided code: if one sentence ends with a given word, then this word will always "terminate" any sentence, even if it is almost always inside a sentence.
Ex: "I like the letter i" will put "i" in the END dictionary, and as soon as this "word" gets picked up the sentence will be terminated, leading to incomplete / low-quality results :/
I like the trick of not using a weight or probability but just the number of occurrences of the world for in-sentences words (that don't scale well but are totally useful with small size training sets), maybe there is a way to reuse the same trick to not always terminate on such END words.
One important thing is to report the phishing attempt, both to the hosting providers involved and to the mail service used to send the emails.