You can now turn on the “autoscrolling” feature of the Libinput driver, which lets you scroll on any scrollable view by holding down the middle button of your mouse and moving the whole mouse

Am I crazy, or did this used to be a feature? And not just in Firefox

It’s a Windows feature that never really made it to Linux. I used to miss it but honestly, middle click paste feels way more useful to me now

Maybe Redis/Redict? The development on that seems pretty dead.

There are cameras and physical buttons that you might want to use on the phone, and the fold might make it nicer to hold in one orientation. Also, the limitation exists because splitting the apps across the shorter side can make very awkward layouts, at least on small phone screens - no such problem with a square. I see no reason not to have the option of both layouts no matter its physical orientation.

I’ve never used a foldable though, so take my opinion with a grain of salt.

Yes, that’s exactly the problem - there’s nothing wrong with the encryption used, but it’s IMHO incorrect to call it time-based when it’s “work-based” and it just so happens that the specific computer doing the encryption works at a given speed.

I don’t call my laptop’s FDE time-based encryption just because I picked an encryption that takes it 10 seconds to decrypt the key.

def generate_proof_of_work_key(initial_key, time_seconds):
    proof_key = initial_key
    end_time = time.time() + time_seconds
    iterations = 0
    while time.time() < end_time:
        proof_key = scrypt(proof_key, salt=b'', N=SCRYPT_N, r=SCRYPT_R, p=SCRYPT_P, key_len=SCRYPT_KEY_LEN)
        iterations += 1
    print(f"Proof-of-work iterations (save this): {iterations}")
    return proof_key


def generate_proof_of_work_key_decrypt(initial_key, iterations):
    proof_key = initial_key
    for _ in range(iterations):
        proof_key = scrypt(proof_key, salt=b'', N=SCRYPT_N, r=SCRYPT_R, p=SCRYPT_P, key_len=SCRYPT_KEY_LEN)
    return proof_key

The first function is used during the encryption process, and the while loop clearly runs until the specified time duration has elapsed. So encryption would take 5 days no matter how fast your computer is, and to decrypt it, you’d have to do the same number of iterations your computer managed to do in that time. So if you do the decryption on the same computer, you should get a similar time, but if you use a different computer that is faster at doing these operations, it will decrypt it faster.

It’s a very short Python script and I’m confident I get the general idea - there’s absolutely nothing related to current time in the decryption process. What they refer to as a “time lock” is just encrypting the key in a loop (so the encrypted key from one loop becomes the plain text for the next one) for the specified duration and then telling you how many iterations were done. That number then becomes a second part of the password - to decrypt, you simply provide the password and the number of iterations, nothing else matters.

Yeah, even the TLDR makes it sound more like Qualcomm is yielding to the pressure from OEMs who want to be able to offer longer updates