I don’t agree. As a single counter example of many YouTube has a huge wealth of information and content.
Maybe that value isn’t worth the ads, that is much harder to say for certain. But it is clear that there is some valuable information on some sites that are supported by ads.
They’ll brick your device if a part can’t be verified so that isn’t much different they destroying. Maybe they don’t require repair shops to hand over personal info, but they do require device identifiers so I wouldn’t be surprised if that is basically identical.
Is this worse? It sounds pretty similar.
How exactly does Samsung police this? Surely the repair shop could just… not tattle?
Well there is a contract in place and there would be consequences for not upholding the agreement. Sure, they could probably get away with it for quite a while. But it likely isn’t worth the risk, they would rather just out Samsung as being a piece of shit and go on their merry way.
It would be pretty easy to catch this as well. Samsung can just occasionally submit a phone with a known third party part for repair and see if the expected report comes in.
I’m sure some people will demand it. But for 99.9% of the population you don’t need 1000Hz content. The main benefit is that whatever framerate your content is it will not have notable delay from the display refresh rate.
For example if you are watching 60Hz video on a 100Hz monitor you will get bad frame pacing. But on a 1000Hz monitor even though it isn’t perfectly divisible. the 1/3ms delay isn’t perceptible.
VRR can help a lot here, but can fall apart if you have different content at different frame rates. For example a notification pops up and a frame is rendered but then your game finishes its frame and needs to wait until the next refresh cycle. Ideally the compositor would have waited for the game frame before flushing the notification but it doesn’t really know how long the game will take to render the next frame.
So really you just need your GPU to be able to composite at 1000Hz, you probably don’t need your game to render at 1000Hz. It isn’t really going to make much difference.
Basically at this point faster refresh rates just improve frame pacing when multiple things are on screen. Much like VRR does for single sources.
My problem is that I do red, blue, green then can’t think of any more clearly visible colours.
You could go columns for the content, but I think my ideal layout would still have the main content in a single column. I would put all of the chrome horizontally through. For example no header before and footer afterwards, put everything in different columns. Maybe even throw some extra navigation on the screen.
You don’t need to use every pixel, just avoid putting things offscreen unnecessarily.
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.
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.
My biggest problem with hardware keys are replacement. If I lost one of my keys and get a replacement I would now need to go to a hundred sites and enroll the new key (and remove the old one). Until this workflow is automated I can only reasonably use hardware keys with a small number of “critical” accounts.
So for 99% of sites I’m going to use a synced software key.
Yeah, a lot of these were lessened because the task was easy without any knowledge. I like the iPod one because the UX would be unfamiliar to someone who didn’t use it. But things like “Type {phrase} into the search box” are really just a lame way to make a reference.
I’m a millennial and didn’t know who that is. But I don’t know any actors so unsurprising. I did end up just figuring out which face was the most popular and selecting that.
But the rest were fairly easy. I still don’t know what a Skibidi toilet is though.
But… PAKE is used as a method for ongoing exchange of messages
I don’t know what you mean.
In really don’t see it that complex, in my last job IT installed a passkey in my laptop
They can also install a randomly generated password just as easily.
Sending passwords is insecure because if an attacker gets the password, you lost
That is why you use a PAKE, you don’t send the password.
Old people won’t adopt it unless forced
They also won’t adopt passkeys unless forced. What is the difference?
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:
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/
Even if the code isn’t reused adding names to sub-expressions can be very valuable. Often times I introduce new functions or variables even if they are only used once so that I can give them a descriptive name which helps the reader more quickly understand what is happening.
To be fair having a name can make things easier to read. I get that i % 2 == 0 is a common pattern and most programmers will quickly recognize what is happening. But isEven(i) is just that much easier to grok and leaves that brainpower to work on something else.
But I would never import a package for it. I would just create a local helper for something this trivial.
To be fair, this is actually reasonable. But it does look stupid on the face of it.
Yup, that “what can I start in 10min” question really ruins a lot of productivity.