Uh, no. Sorry. The IR cannot be transmitted with any fidelity through a thumb. The only way this would work is if you actually weren't covering the camera and IR emitters with your thumb (which is entirely possible because most people don't know where the IR emitters are in the notch)
There’s an app on my phone (IHG ... hotel chain) that logs me out frequently and then repeatedly tries FaceID to log me back in. Except, I have to re-enter my password. Covering the notch with my thumb is the only thing that breaks the cycle and allows me to type my password in.
How so? If google wanted to save bandwidth, they would simply up the cache time of their page(s), baking some version into the browser only saves the very first load. Doesn't seem like a decent strategy to face potential backlash for baking in their search page when the same thing, sans the initial load, can be accomplished with other techniques
> A normal ping will go on forever. We don't want that. Instead, let's limit that to just five pings.
It almost always what I want.
> alias getpass="openssl rand -base64 20"
If you really want to be handy, use "pass generate -c" instead of openssl, you got the password stored in your passstore and temporary copied to the clipboard.
On Mac ⌘ + k works well in iTerm and the stock terminal. I can't be sure if it is a standard thing or not so I'm not going to make any assumptions about it working in other places.
I don't think the people that wrote this know how QUIC works and what its benefits are.
The problem is not QUIC, it's the request API the adblockers use to filter the content. QUIC is a fast, documented protocol used by way more people and organisations that aren't Google.
'Confirm, with appropriate supporting data, that their bid requests made with QUIC are not anti-competitive, and justify why bid requests are being used by a new and opaque request protocol under conditions where competitors are bound to use TCP with its extra round trip overhead.'
Which just looks like they have no idea what they're talking about.
Things QUIC isn't:
- Limited to Google(rs)
- "Opaque" as-is, it's just that the JS APIs are bad. It's still experimental software after all.
I'm using a Hackintoshed Lenovo Y50-70 (FHD model) running MacOS Sierra and i can only recommend it so far, all of the configurations that are being sold are very compatible with macOS. It even comes with a dedicated GPU which is great for GPU-intensive tasks on different OSes - it's disabled whilst running macOS because of missing drivers for nVidia optimus though.
To whoever edited my title: The bug report title is inaccurate. It's specifically about HSTS preloads, which is why my original title stated that instead of "gTLDs".
If you changed a misleading title to make it accurate, then you were following the HN guidelines and we made a mistake in overwriting it. Sorry! We try hard but inevitably get it wrong sometimes. We've put your title back.
Regardless of the title editing discussion in the sibling comments, the title at the source was changed to "Omnibox hostname heuristics misunderstand internal redirects.", which accurately reflects the problem.
That's not what I understood of reading the posting guidelines [0] and especially "Otherwise please use the original title, unless it is misleading or linkbait."
If OP thought it was misleading, then he was right to adjust it?
Indeed the "title" of the original page is misleading (because the original bug submitter thought it was one issue, but was really another).
And that has had the effect that most of the conversation in this thread is about gTLDs instead of HSTS redirects, when the bug has nothing to do with the former (as noted by the comments where they specifically say that this does not happen to other gTLDs)
