jamieweb

I looked into this a few years ago[1]. The solution I came to involves putting the hash of the most recent Bitcoin block in your document, and then signing the hash of your document into the Bitcoin blockchain.

This cryptographically proves that the document was created/published within those two time bounds.

This of course doesn't help in all cases, i.e. you could edit an old document to make it look newer, but I'm not aware of any way to properly solve that particular problem without a trusted third-party.

[1] https://www.jamieweb.net/blog/proof-of-timestamp/

This has been absorbed into an internal repo now, but the original version that I wrote a couple of years ago is here: https://gitlab.com/jamieweb/travis-ci_csp-tester/

cURL doesn't load subresources or honour Content-Security-Policy headers as this is beyond the scope of what it's supposed to do.

I use it to test my Content-Security-Policy by crawling my whole site and capturing any violation reports that are sent.

Cloudflare Registrar - it's one of the only truly security-oriented ones out there, and they offer wholesale rates, which is a nice bonus.

I use Cloudflare Workers for:

* Serving a standard security.txt file for all websites within my account

* Automatically rewriting the case of URLs for a CMS that doesn't support case-insensitivity

* Adding security headers to sites that don't support adding them locally (e.g. third-party hosting)

* Proxying requests elsewhere directly from the 'edge', rather than having to run my own proxy

* Serving static config files, e.g. mta-sts.txt, proxy.pac

Feedly lets you 'subscribe' to YT channels, so you can see all of the uploads in your Feedly feed.

Just search for a channel when adding a source. If it doesn't come up, paste in a direct link to the channel homepage and it'll find it.

For those who've ended up here, my solution for now is to use Feedly.

My main reason for disliking Snap is the fact that it allows anybody in the world to publish a package with minimal moderation. This completely undermines the inherent trust that system package managers should have.

When installing critical system packages, I want to be absolutely certain that these are legitimate/official, and that even if I make a minor error in typing a command, I won't inadvertently install some sort of typosquatted fake version of the package.

When using Apt with the default repositories, this isn't a problem at all, as only known, trusted packages are available. In other words, there's no chance of someone publishing a fierfox or apahce2 package to try to typosquat someone.

I don't even want to talk about the forced automatic updates either... these make it essentially impossible to have a stable/reliable system for specialist use cases, e.g. browser testing, bastion host, build environment, where control over updates is very important.

On the sandboxing - it's good in principle, but rarely seems to be implemented in a truly meaningful way, as ultimately once you have home drive access, you don't even need to worry about escalating privileges as everything valuable is probably in your home area! There's an xkcd about this somewhere...

tac

Just to confirm, this only seems to relate to popcon/popularity-contest, and not the other data collection features.

The other two main ones are Apport for crash reporting, and ubuntu-report, which sends system info if opted-in at install.

Allow developers/engineers to use an OS and tooling that they're comfortable with. There must be choice between text editors, IDEs, browsers, shells, etc.

Also don't try to control this centrally. Once developers have proven themselves to be competent at operating a computer, they shouldn't be forced to use a locked-down corporate machine.

Yes, would love a 'pull' based system. You can usually tell just from the subject/preview whether you actually need an email.

My favourite one is a CMS, which stands for Crematorium Management System.

The tk, gq, cf, ml and ga TLDs offer free registration, so they're widely used in scams and fraud.

In most cases you can safely block all traffic to/from them, as well as email addresses using them.

My recommendation is Fastmail for personal/business email/mailboxes, and Mailgun for a transactional email API.

Pop!_OS

Pop!_OS is what you're looking for IMO.

You can transfer a domain with no downtime. The name servers will remain during the transfer, so as long as your DNS isn't dependent on the domain registrar, you'll be fine.

If you are using the registrar's built-in DNS hosting, move away from this first, which can also be done with no downtime.

I love your service, I use it every day. :)

I find that a lot of phishing sites these days are hosted on legitimate sites that have been backdoored, but are continuing to operate as normal.

The phishing page is hidden away in the /.well-known/ directory or another similar one, so the website owner is non-the-wiser.

As a side note, I was very impressed/delighted by the message on the site when JavaScript is disabled:

> Sorry pal, but this won't work without a JavaScript. You are probably doing that for privacy reasons, and I do respect that. I tried to handle the noscript case gracefully, but there is only so much I could do. You can download this website, inspect the source code, and run it locally. Or, if you think this website is trustworthy enough, you can whitelist it in your browser or a script blocker. I don't have any third-party trackers on this website (only a CDN), so you will be safe here.

A somewhat relevant project of mine, where you can test how good you are at spotting these sort of domains: https://www.jamieweb.net/apps/lookalike-domains-test/

Relevant: https://publiccode.eu

This is especially concerning considering that GitLab is a technology company consisting of mostly technical staff.

For a crafted spear-phish like the one used in this test, I wonder what the failure rate would be in larger, non-tech organisations?

Ah yes, I love working out which is the most recent document out of:

* Document1 FINAL

* Document1 FINAL DRAFT (DO NOT EDIT)

* Document1 FINAL EDITED

* Document1 v2 FINAL

I'm interested to know whether the SHA256 hashes are just done on a TOFU basis, or whether they actually verify the Authenticode/GPG signatures of the EXE files to get an 'authoritative' or 'trusted' hash.

Most users will click straight through the approval though, like when they granted it full permissions at install.

And is the signing actually effective anyway? There's very little mention of it online, and as far as I can see it isn't covered in the official guide for publishing extensions.

Is it even possible to have proper signing keys stored locally or air-gapped?

To be honest that problem exists for essentially any software that auto-updates.

You just have to hope that the built-in integrity checking (if any) works and is effective.

That's why I like software distribution methodologies that rely purely on signing to verify authenticity, rather than simply the location that it was downloaded from. I can technically use any old dodgy Apt mirror that I want, as long as I only accept packages signed by trusted keys.

As a side note, it's shocking how many software providers say that their downloads are 'integrity checked' just because they're served over HTTPS.

A pair of $5 cloud servers and a Cloudflare load balancer for resiliency.

Ansible is used to build and maintain both servers, and the actual web content is in Git.

I use `receive.denyCurrentBranch=updateInstead` in the repo config on the servers, so I just do a push to each and the new content goes live instantly.

The reason for doing it this way is that I want to fully own my platform. I have fine-grain control over all of the web server headers, PHP configuration, etc.

https://www.jamieweb.net/