This is absolutely true. The demo in the original article seems quite deceptive in that respect. Nobody would attempt to resize a window by launching their cursor at the corner with great speed as the demo shows. The resize pointer seems to show in exactly the right place, and allows for an extra hit area slightly outside the rounded corner — I don’t see any problem with that.
As for the fact that one cannot resize from inside the window, it makes absolute sense for every other corner of the window, where the user would instead be clicking an icon or some other button (try the top right corner of the finder, where the search button sits).
So, while I agree on the whole that Tahoe is a huge step backwards in terms of design, this seems like an odd gripe to point out, as it doesn’t in fact seem to be an issue at all.
> As for the fact that one cannot resize from inside the window,
if you check the screencast I posted, you'll see that you can indeed resize from inside the window. Not by a huge margin, but definitely from inside the actual window boundaries.
Indeed, just enough. And the correct resize pointer shows all along the rounded edge, so I agree, this doesn’t seem like the problem it’s made out to be.
I’m referring to the demo in the original article. The mouse pointer moves rather rapidly onto the inside of the window. You can just about see the resize pointer flashing as the user does so. I don’t think I ever attempted to resize a window with such erratic mouse movements. Approaching the corner at reasonable speed shows the resize pointer where expected.
> I’m referring to the demo in the original article.
The article from noheger.at? I am also referring to it. My guess is that the pointer speed is exaggerated due to zoom of the gif, and/or that we are using the mouse in different ways.
Yes, that demo. You can clearly see the resize pointer flashing briefly, but the user continues aiming right inside the window. I’m not sure why he’s not stopping when the resize pointer appears. It seems erratic.
Arguably the feedback via the cursor change is feedback to help you learn, like the icons that appear in the close / minimise / zoom, or stickers on the keys of a musical instrument. You pretty quickly learn which one is which, or you can't use them effectively. At some point you'd hope that common actions become muscle memory.
So if it was something that was learned whilst using the previous version, and worked, I'd argue it wasn't 'erratic'.
There are 2 in quick succession in Marple ([1] and [2]), very near the Marple Lock Flight ([3]). This happens to be at the very start of Macclesfield Canal.
Just installed it to see if it might be better than AdGuard on memory usage, and now I’m getting constant “Pssst! You forgot to apply some settings” notifications as soon as I leave the app. Clicking it takes me back to the app, where it does an update of everything, and… That’s it. Leave the app again, and the notification reappears. Quite annoying!
Edit: it appears it doesn’t remove ad content blocks like AdGuard, and doesn’t let me pick and choose elements to add. I might revisit in a few months, but for now I’m back to AdGuard.
>Just installed it to see if it might be better than AdGuard on memory usage
Why would it be? All adblockers are using the same content blocking API, so at best you'll be using less memory usage while it's updating, which happens so rarely that it's not worth worrying about.
Change the password for what account though? The dashboard doesn’t seem to list the actual website(s ) linked to the email/password breached, so how am I to know which password to rotate?
If I follow the recommended best practice, I have a different password for every website or service. That could be hundreds of them. Am I supposed to rotate all of them every time there’s a breach?
The details about the “Stealer Logs” on the dashboard even state:
> The websites the stealer logs were captured against are searchable via the HIBP dashboard.
There is no way to use the HIBP dashboard to figure out what domains my email address appears against.
Am I meant to change all passwords associated with that email address? Or do I need to get a paid subscription to query the API to figure out exactly what password(s) to change?
This has always confused me. On the one hand, HIBP is an invaluable service, but, on the other, it does nothing more than stating you’re in trouble, with no clear way forward.
It's quite certainly a up selling attempt. I once spend a couple of hours to see what was actually exposed in the infostealer breach my email appeared (eg: payment data? Physical address? Government id ?) to no avail.
Respectfully, in context of my claim (that this is upselling attempt), your answer is untrue.
"You need an active subscription in order to provision an API key".
This is minimum $4.50 pm. Of course it's not a lot but let's not move the goalposts by discussing whether it's a fair price or not.
I don't want to say it's a lie, because I assume you didn't know.
API is a paid service, not free.
Separately, if I open the dashboard link while being logged out, the Web page promises:
"viewing stealer log entries that captured your email address"
Needless to say, this is also false (maybe true with a paid subscription?). If I click on the Stealer Logs in the dashboard it only shows "discord.com" (old account I used with this email was deleted years ago), and nothing else. Even though Breaches suggests there's something else.
Only if you want to search by account. If you want to search by password, it's free. You can query all your passwords to see which ones are breached, and change those.
> Authorisation is required for all APIs that enable searching HIBP by email address or domain, namely retrieving all breaches for an account, retrieving all pastes for an account, retrieving all breached email addresses for a domain and retrieving all stealer log domains for a breached email addresses. There is no authorisation required for the free Pwned Passwords API.
And searching by account wouldn't tell you anything useful. It would just say "Synthient Credential Stuffing Threat Data". It wouldn't tell you what password to change, because HIBP doesn't know what site the password(s) that it found in "Synthient Credential Stuffing Threat Data" were associated with, and HIBP doesn't maintain a database linking passwords to emails.
Sorry, I missed that you were talking about stealer logs. This specific credential dump of 2B emails wasn't a stealer log, so stealer log info will not tell you anything about this specific credential dump.
You're right that the API for stealer log info isn't free.
However, the dashboard can provide you information about stealer logs for free.
If a text-heavy website does not constrain the width of its content, what do you tend to resize the browser to? Does it depend on text size? Or other factors?
I tend to not resize the browser ever, except when developing/testing sites to make sure they render properly on different screens sizes. I use a 27" monitor and I like reading full-width. As I said in my original comment, I find the act of syncing my eyes with scrolling text to be very distracting, whereas reading a very wide column of text to be very easy. Depending on the website's default font face and size I might use the browser's text zoom feature to enlarge the font, but I still like reading full-width.
Interesting. I would say you’re definitely the minority here, and I would still argue that limiting content width does work better for most.
When you say you sometimes enlarge the font, how many words per line do you aim for or end up with, roughly? You’re describing behaviour that aims to render text more readable, so obviously it isn’t simply a case of “I like text content to be as wide as possible”.
I have no doubt I'm in the minority. My preference is basically the more words on a line the better, to reduce as much as possible a) my eyes jumping to the beginning of the next line, and b) having to scroll the page and have my eyes sync to the scrolling. The only reason I enlarge the font is to make it large enough to read comfortably. I don't make it too big, though, because then the lines start to become shorter, and I'm back to the original problem: having to keep jumping to the next line, and scrolling fairly often (which is my biggest complaint because I find that even more distracting than moving my eyes to the next line).
Interesting choice of example. I would probably have gone with the PayPal or eBay apps, which (on iOS at least) still refuse to let you select the text from the address you have to send the item you’ve sold to.
Is the biometrics step (fingerprint reader) on macOS much different from a ubikey? I imagine implementation may have some differences, but in practice it seems I can already protect access to my GPG key using the built-in reader, so what’s the advantage of ubikey in that respect? Genuinely curious.
The TouchID is bound to a device - of course, I could copy my secret into a secure enclave that is only accessible through TouchID. Could even just store my GPG key there. With a Yubikey, I generate the key on an airgapped device and store it on the Yubikey. No other piece of hardware ever needs to see my secret key in plaintext. I could achieve the same with TouchID, generate the secret key inside the enclave, but then I cannot move the secret keys out without some other computer baring witness to that.
I really do not want to give Apple any more leverage over me, I'm looking to minimize it.
The argument that cyclists (implied: all cyclists) ride at full speed on pavement at all times is akin to arguing that cars (implied: all cars) go over the speed limit at all times. It’s daft at best, and utterly outlandish.
You should stop and have coffee in a street shared only by pedestrians and cyclists, and observe the behaviour of cyclists. I have observed it to be mostly slow, controlled, courteous and respectful of pedestrians.
I picked up my son today at the kindergarten, and we walked for 25 minutes back home. Here in Riga most cyclists go on the sidewalks, I'd say that 2/3 of them don't respect a minimum 1.5 meter safety distance, and about the same amount go as fast as they can. I stopped and scolded a food courrier (who is incentivized to go as fast as he can) who was slaloming between pedestrians as if it was a game.
No, I don't feel safe at all, and my son can't walk freely either. In Paris it's the same (my wife, who was pregnant then, got hit at a crosswalk by a cyclist who seemed to believe that red lights were for cars only). Even Le Monde published an piece about it!
As for the fact that one cannot resize from inside the window, it makes absolute sense for every other corner of the window, where the user would instead be clicking an icon or some other button (try the top right corner of the finder, where the search button sits).
So, while I agree on the whole that Tahoe is a huge step backwards in terms of design, this seems like an odd gripe to point out, as it doesn’t in fact seem to be an issue at all.
Edit: clarification
reply