pilif

Given that win 3.11 doesn’t change, you can expect the old version to keep running too

If that were true, then browsers should drop support for VP8, VP9 and indeed AV1 because the MPEG-LA is claiming ownership of patents covering those codecs.

That's the thing with this kind of "protection". If your proprietary app needs to access the server, anybody who can either extract the key from the app with reverse engineering or who can listen in on the communication between app and server will be able to use that API.

It's the same issue as with DVD encryption: If you need to show the movie to people, people need to be able to decrypt it. If this needs to happen offline, then the material needed for decryption must be static and either be on the disk on in the player - where it can be extracted and used by third parties.

Also, I'm unsure as to how the monitor type would have any impact on the screen real-estate available to the OS. If the OS is rendering an 800x600 screen, then there are 800 pixels of room available horizontally and 600 vertically, no matter the screen technology.

Given a 32 pixel size of an icon for example, there's would be room for 25 icons horizontally with a 800x600 resolution but 50 icons on a 1600 resolution. The screen technology does not factor into this at all.

What I do give you that it's probably possible to drive a CRT monitor of a relatively small size with larger resolutions because pixels can be infinitely small, though, as I said in the beginning of the comment, at some point you will get issues with sharpness and things become blurry.

The standard library is becoming cross-platform as we discuss it here.

In the case of this barcode scanner all communication was done over the control endpoint though.

In the end I sniffed the USB protocol of the windows driver and was delighted to see how they abused the control endpoint rather than setting up proper data endpoints.

I was so happy when my Mac application was able to talk to the scanner and, compared to windows, completely without any driver installation thanks to user-space IOKit on macOS.

Writing software to make hardware beep is even more fun than writing software that doesn't involve hardware making noise.

One of the big reason to not do that in the past was in order to disconnect the presentation from the page structure, but if you have individual classes for each individual css property, you're back at tying the two together.

What am I misunderstanding here?

Just like we have CI checks to make sure nobody accidentally commits a secret (like the GitHub host key thing last week) we have checks that prevent debris to be committed and code to be formatted according to agreed-upon coding standards.

All of this might seem superfluous when the live expectancy of a repo is measured in months or single digit years, but then, no solution or repo is more permanent than a quick throw-away one.

Which is why this isn't even a discussion but just a reality. Been there, done that, learned my learnings.

Our CI.

And code review is what prevents .DS_Store to be added to .gitignore.

And, again, I'm saying this as a purist with a developer team of 99% Mac users.

People working on Linux or Windows do not need to know about garbage your dev env leaves on your machine.

I’m saying this half-seriously as I fully understand that these are so common, it’s more convenient to have the exclusion synced between clones.

That said, as a purist, none of the repos I’m watching over have .DS_Store in their gitignore

What eSIM does is turn the physical smart card into a QR code which can be shown on a screen in addition to being printed on a piece of physical paper.

That really depends on the carrier. In my case, setting up a new iPhone to replace an old one means saying yes in the prompt displayed by the phone. Nothing else. This is more convenient than having to search for the SIM removal tool.

> -you can't just hand over your phone to someone else, you have to unroll yourself and enroll the other person

For me this is a big feature because I would never hand my phone to somebody else, but an attacker is very likely to remove the SIM card and put it into their phone. Now suddenly many 2FA accounts are protected by a 4 digit PIN rather than my 20 digit phone passphrase.

> -you don't have anonymity and privacy since is no longer possible to use a prepaid physical SIM

It works exactly the same way as it did with physical SIM cards only the physical card is replaced by a QR code displayed on a screen or a printed paper. If the carrier sells anonymous prepaid SIM cards, nothing prevents them from selling anonymous prepaid QR codes.

any file format you support poses a significant attack surface, especially an old and creaky one whose parser you've written in the 90ies and ever touched.

Reaching into another account‘s home directory to remove stuff feels very intrusive.

Which would mean that any uninstall trying to also clean out library data is going to be incomplete.

I think the consistent behavior of always keeping it is a win

Requires zero user action to make up an address

Once I left school behind me and met people who respected me, I managed to let all of that past behind me and become a very happy person with (so far) zero depressive tendencies. There is still some trauma left when I see my kid being teased or teasing somebody (to a much smaller scale than what I went through), but aside of that I'm very glad my brain managed to escape hell unscathed.

Even on slow devices, password managers can employ techniques to help like only using the full count of rounds for a cold start but then re-encrypting the key for the vault key with fewer rounds but only keep that copy locally.

That way a user of a very slow device only needs to wait for, say, 10s once on first unlock.

While this is a downgrade in security, it's still better because now the key with the small amount of iterations is confined to the one device, not available on the server where an attacker can get bulk access.

Of course, devices where 1M PBKDF2 iterations take so long that it's noticeable are probably also old enough to be full of unpatched (due to EOL) security holes which makes such devices the weakest link anyways, but this would still be a better situation because this way not all users are punished because of one user's slow device.

Syncing password managers solve all these issues and, if they do encryption right, there is nothing that could possibly happen even if they are hacked and an attacker gains access to my encrypted data.

The doing it right part is why I was asking my questions with regards to PBKDF2.

how so? The iteration count must be part of the non-encrypted parts of the vault data. If a client is offline, it will use its locally stored vault with the old (lower) iteration count. If it's online, it will have the updated vault with the higher iteration count.

> The second issue is that the transcryption would have to be done on login, which is a pretty shit UX as the user logs in then immediately gets locked out for however long it takes to convert the store (then again for most people I’d assume the payload is not enormous).

You could do this asynchronously in the background: Decrypt the vault, store it in memory (which all password managers do for some amount of time in order to provide any UI), re-encrypt, store to disk, send blob (which will continue an unencrypted iteration count) to server.

But this is the complicated case where the vault is re-keyed. What would totally be sufficient is to re-encrypt the same value key using a new hash derived from the same password, only with more rounds which means that the bulk of the vault blob won't change - only the password-derived key and the iteration count.

If any of this happens simultaneously on multiple machines, treat it the same way as you already treat editing conflicts (I'm not offering guidance there - this is a hard problem that each cloud provider is already solving one way or another).

> They are but needing to update the work factor as hardware progresses remains. In fact scrypt and argon have more work factor knobs than pbkdf2, which only has the iterations count.

Given the current state of the art and given these two algorithms, I think it would need to happen significantly less often than with PBKDF2, so if there's something that would need to cause the UI to re-lock immediately after unlock as you think (and I'm not sure about) then having argon or scrypt in the loop means you have more time between causes of shitty UX.

This should absolutely be application managed and gradually increased over time.

Also: while I understand that FIPS is the reason why we are stuck with PBKDF2 in the case of the more enterprisy password managers, wouldn’t it still be FIPS compliant to do some scrypt or argon rounds on top as a means of not constantly having to update the PBKDF2 iteration count (assuming that scrypt and argon are more resilient to hardware brute-forcing)?

The local thing would work, but of course only for local hosts.

It would not be worse than using plain http and my personal opinion is that visiting a plain http site should have the same UX as visiting a self-signed one.