It's never too early. If you see an interesting job posting reach out and go thorough the process. At worst you learn a bit about what they were looking for and gain some interview experience. At best you get a job offer. Even if you decide not to take the offer you learn a bit about the positions available to you.

It costs effectively nothing to apply. Just a few hours of your time.

I don't know about YouTube but the chunks are often a fixed length. For example 1 or 2 seconds. So as long as the ad itself is an even number of seconds (which YouTube can require, or just pad the add to the nearest second) so there is no concrete difference between the 1s "content" chunks vs the 1s "ad" chunks.

If you are trying to predict the ad chunks you are probably better off doing things like detecting sudden loudness changes, different colour tones or similar. But this will always be imperfect as these could just be scene changes that happened to be chunk aligned in the content.

Exactly this. It isn't even really "stitching" as YouTube videos are served as a series of short chunks anyways. So you simply tell the player that there are a few extra chunks which happen to be ads. There is no video processing required it is basically free to do it this way on the sever side.

I wrote my own. I aimed for a different UX than most services. For my use case I have a few devices that I often share files between. So opening the tool on both devices was a bit annoying. Instead you select the file on the first device and you get a push notification on the other. Then the transfer is done over WebRTC (locally if possible). All communication is done end-to-end encrypted and over your browser's push service.

Hosted: https://filepush.kevincox.ca/

Source: https://gitlab.com/kevincox/filepush

Yeah, this is important to realize. Most good 2FA implementations offer TOTP which doesn't need a proprietary app. You can store all of your 2FA secrets in whatever app or password manager you like.

It is also worth noting that Firefox Sync is end-to-end encrypted. So the amount of data the server gets is quite minimal. (This is unlike the sync of a lot of other major browsers.) So unless you want to hide your IP and activity times from the host self-hosting isn't critical.

I am willing to help with moderate. I have minimal existing moderation experience but have a long posting history and online presence.

I will not be able to commit enough time to be a sole moderator, but can help out as part of a team.

There are dozens of first-person shooters but people love porting Doom to every device. Winamp is memes and nostalgia, I would bet that people would port it just for fun.

I bet someone will have it running on Linux within a week.

deleted by creator

It's a greeting. It is meaningless other than a polite gesture. Just like when people say "Good morning" they aren't really wishing that person a good morning, just saying something friendly.

Plus the response is naturally escalated based on how well you know the other person. The first time you walk into a shop it is "How are you?" "Good, you?" "Good thanks" But if you have been getting your morning coffee there every day for a year maybe you do actually share something a bit personal. Probably starting off with a positive "Great, I found $5 on the street this morning" and eventually becoming personal and maybe even saying something like "Not great actually, ...".

So it is actually a nice way to transition into a more intimate conversation as you get to know someone.

I would definitely go for Irish sheep farmer. You get to live in a cute little house in a green pasture by the seaside and the sheep feed themselves. What do you need to do? Sheer them every once and a while? I'd take that over Terraform any day of the week.

On NixOS I did this:

services.displayManager.autoLogin = {
	enable = true;
	user = "kevincox";
};

# Avoid setting up a keyring every time I do a non-auto login.
# https://gitlab.gnome.org/GNOME/seahorse/-/issues/159
security.pam.services.login.enableGnomeKeyring = lib.mkForce false; 

I like the option to preserve originals. I wonder if this is now always done or if it is configurable. Often times I am preserving the original footage and project files anyways so don't need an original. However other times I am just throwing footage straight from the camera and the archive is nice.

It also opens interesting possibilities like re-encoding down the road to new or better codecs or even just better encoders. For example it would be interesting to dedicate one background thread to re-encoding in a much higher effort, and possibly re-running this every few years to take advantage of encoder upgrades.

Most archiver programs will set the modified time of a file to the modified time recorded in the archive (if present). Many archive formats support recording modification times because they were intended for backups and aim to perfectly record the original files including all data and metadata.

I also agree that this is not what I want when using GUI modification programs (in my case file-roller) but the exact options available will depend on which program you use.

Great question. Modern encryption schemes are usually composed of a handful of primitives. If we consider something like HTTPS it uses both asymmetric and symmetric parts.

Asymmetric encryption is the "magic" that you are missing. Asymmetric encryption algorithms create a keypair, one half of this is the "public key" which can be used to encrypt messages that can only be decrypted by the "private key". This means that even if the public key is public (as the name suggests) the messages can't be decrypted without the private key.

You can think of this as giving someone an open padlock. They can put something inside a box and lock it using the padlock, but they can't open it without your key.

Using this you could come up with a very simple protocol for establishing a secure channel:

1. The server sends you their public key, along with a certificate that proves that it belongs to them.
2. The client then uses this public key to encrypt a key for symmetric encryption.
3. The client sends this encrypted key to the server.
4. The server decrypts the key.
5. Now the client and server can both use the shared key to communicate.

(Note: There are many missing features from this system, but I think it illustrates the point. Don't design your own crypto.)

https://en.wikipedia.org/wiki/Password-authenticated_key_agreement

Cloudflare also had a fairly good post a while ago about a newer PAKE algorithm: https://blog.cloudflare.com/opaque-oblivious-passwords

a scary amount of users are using the same rather weak password for lots of different accounts

This is true, but you can force them to use a random password just as easily as you can force them to use a randomly generated key. The end UX can look basically identical if you want it to. My point is that this is basically a UX problem. Instead of just making the change we are inventing this new protocol to shuffle along a UX change at the same time. Maybe part of this is because the change has major unaddressed downsides that would be too obvious to slip by if made as an incremental upgrade to passwords.

One team person does the login, adds a key, then let’s the second team member put in their key and so on.

There is no reason you can't have multiple passwords associated with an account.

I also find passkeys to be underwhelming and hope they don't catch on. It seems like a huge mire of complexity for very little gain. It seems like there are two main goals here:

1. Don't sent secrets to the sever.
2. Stop phishing.

Both great goals. However I wonder if we threw out the baby with the bathwater with passkeys.

A password manager is already a huge step to blocking phishing, because if the password doesn't auto-fill you get super suspicious. If you push your user to randomly generate their passwords then they also don't remember them so would have to look them up, then copy them over. If you are worried about users who are a risk to themselves you can make the route to extract a password from the password manager as complicated as you like.

As for not sending secrets to the server I think using a PAKE would have been a great option. If this was paired in a browser-integrated password manager it could be very secure. Think about some type of form field that can be filled with a password that isn't accessible to the page itself. The browser would then tag the password as PAKE and never expose it to the page again.

Another cool think able PAKE is that they can also authenticate the server. TLS-integrated SRP was very cool like this as you could have a self-signed certificate but verify it by entering your username and password. The UX may not have been good enough for public sites but it was an amazingly easy and secure option for private sites. This would actually be more secure than a PKI signed certificate as you aren't risking CA compromise. That being said integrating this with browsers with good UX may be quite difficult. I would love to see it.

But the biggest thing we lost was understandability. Even my grandmother understood what a password is. She knew how to back it up, how to transfer it to a new device. She could use it in two different browsers without setting up some multi-browser sync tool. She could write it in a notebook and log in at the library computer.

I really think that we should have just iterated on passwords. Switch to a PAKE and keep improving password-manager UX and pushing most users to auto-generated passwords. So much was lost by switching to a system that most users don't understand.

I wrote a blog about this a while ago. https://kevincox.ca/2022/04/07/passwords/

It really is a better name.

Honestly there is rarely a blog I want to follow that doesn't have it. I do think it would be great to have more readers using it so that it becomes more significant, but for my reading it is actually pretty great.