skysight-inc/HackerNews huggingface dataset:
As a result, it seems like the only way to have a chance at unlocking such Pixel phones, which have been made by a US company and purchased from a US carrier, is to pay someone in China and hope for the best. It has gotten that far.

That reminds me of the right-to-repair article about patched John Deere firmware created by Ukrainian hackers.

It wouldn't surprise me that China has the same skills. I remember coming across a lot of products made to unlock/unbrick Apple's products too, although that was many years ago and I'm not sure if they've gotten through Apple's security for the newer models yet --- and it wouldn't surprise me if they knew but won't easily disclose.
Block of paper and the first pen I can get my hands onto.

Blue light blocking glasses.
You're right an interpreter is not a runtime. However V8, JSC, SM, ... aren't just providing you an execution engine. E.g. they are providing all the core objects, APIs, etc that are equivalently provided by the "Visual Studio Redistributables for C++" which you seem happy to call a runtime.

The lack of direct IO is irrelevant. You can take any of these libraries, and execute arbitrary JS, and then display the output (Serenity's spreadsheet uses LibJS for equation cells IIRC). E.g. JS that runs and uses the "runtime environment" to do things.

Your particular use case may benefit from exposing some additional APIs to JS, and all these libraries allow you to do that. But exposing, for example, printf to a full JS runtime environment does not mean you've made a runtime. The belief that for something to be a "runtime" it must have built in IO routines me that no generally usable scripting environment could be a runtime.
If the root comment is to be believed, this (connecting via the internet to Google's servers), is required to provide additional security. I'm just taking that as true and deciding that connecting to the provider of my phone's hardware and software _once_ as a purchaser of their hardware, is fine for me. I also imagine it's not too burdensome for others.

Scenarios in which that's not possible are hypothetical (disaster, totalitarian takeover, alien invasion, sudden policy change), and I'm fine calculating that into the risk calculus and deciding that, yep I don't mind driving home and unlocking it the same day I bought it and praying nothing changes in their policy during the drive.

That's basically what I did. We can disagree on this, but it has worked out OK so far.
> google, the company making the big passkey push

Google had a recent blog post about it, but the push started with Apple at WWDC22 (and one session at WWDC21), to the point some assumed it was an Apple-only feature. An effort like this requires coordination from major players to take off with the impact they want (replacing passwords).

https://www.theverge.com/2022/8/5/23293643/apple-passkeys-fi...

1Password has been tracking services which support passkeys, and so far adoption seems slow. I’ve been checking their website on and off for months and it has hovered at about the same number of websites, occasionally going down.

https://passkeys.directory/
> Does FIDO have a method to require keys are stored on devices certified to a certain level?

yes: https://developers.yubico.com/U2F/Attestation_and_Metadata/
I wonder what’s the point of this kind of “declarations”. Do you want to hire locally? Can you satisfy your headcount needs? All great (unless you’re changing conditions on workers which were hired to be permanently remote), it’s your company, you make the rules.

But hiring locally means having access to fewer people and/or needing to pay more. It’s a tradeoff. Very few workers will say “ok I will move to SF from some remote area and keep the same salary.”. Some will quit, some will ask for a significant raise.

Unless you’ve got some kind of “vested interest” in office space value; then you should disclose it before discussing remote work for others.
There is more SFBA startup reality in Silicon Valley than there is in a lot of these docudramas about startup flameouts; even The Dropout, which is the best of them, is much worse than Carreyrou's book. Honestly, Silicon Valley has so much verisimilitude that it suffers from it; towards the end, it starts to veer into fan service.
> I couldn't disagree with more from a hands on practical perspective. That will 100% take anyone longer to spin up for an MVP (for more cost) than spinning up a FreeBSD server and I'm unaware of anything that needs more than that for an MVP.

I agree with OP. If you hand me a binary and instructions on how to run it, I can have it running on either AWS or DO in a container, connected to a managed database with snapshots enabled in about 30 minutes. If the toolchain is easy to set up, I can have CI/CD with 0-downtime deployments with auto-rollback in another 30 minutes, and you won't need to touch either of those until you're hitting thousands of concurrent users for a typical web app.

> you are not only telling them what kind of data you have (don't pretend like the hosts don't know and can't tell)

this is FUD of the n'th degree - if you suspect AWS are spying on your managed RDS data, I don't know what to tell you.
The desktop Ryzen 7000 parts are still saddled with power-hungry die-to-die interconnects and an IO die that's built on an older fab process (though not quite as old as previous Ryzen IO dies), so the idle power is horrible. And the parts without the 3D stacked L3 cache will happily crank up the voltage to crazy levels in order to get the last few percent of clock speed. But if you cap their power/voltage/frequency to reasonable levels and look at the power consumed by just the CPU cores, it's clear that AMD has a very promising building block to use for their monolithic mobile processors.

But I agree that AMD's marketing claims as filtered through low-quality journalism that doesn't even distinguish between peak and base power consumption is a poor way to judge whether AMD has succeeded in building a great low-power processor.
Interesting. Since I TL KV currently I’m particularly interested in the ways it’s not working for you. We’re in the process of rolling out major changes here that might help you here so hit me up on the KV Discord or my username at cloudflare.com. I actually do have a meeting with the Cache team on Monday about something related and I’ll ask about it if you could message me what specifically is broke / what the semantics you want are (I’m not intimately familiar with all the HTTP semantics).
Where I'd consider a (good) CTO should be somehow responsible for the high-level architectural decisions. Accumulate enough expertise and know-how (via "architects" or rather very senior engineers) and then discuss the pros/cons and at the end weigh each argument and decide what may work best.
Perfect wasn't the right word to use, but in the age of LLMs, deep fake images, video, and voice; No one should take to heart anything they see on these screens.

Don't take this the wrong way, I have no reason to believe that you're a real person and not a fun contrarian bot. And you to myself as well. :)

In either case, our wetware isn't suited for social interactions at this scale. I think small, invite only, social rings are much better than what we have now. Yeah, people are going to play silly games, but we won't see a solution to that for a very long time.

As for the people who are eager to explore the edges of controversial ideas; they should be aware of how to discern a group that values progression through challenge over one that demands consensus, and steer clear of the latter.

And to your final point about being useful to the world, it would be better to strive to build a system useful to just your loved ones and local community. Plenty of people exhaust themselves over words on a screen from fake people on the other side of the planet. We have enough ancient and contemporary text from philosophers and religious leaders to remind us that people, specifically the people physically around us, matter more than anything. But of course, there's no money to be made with IT cookbooks, so we don't talk about them.
>The major difference between passkeys and ssh keys is how they are managed. You can, and should as good practice, generate separate ssh keys for each ssh service that you use, just as you should generate separate random passwords for each web service that you use.

The two cases seen entirely different to me. I think that in most cases a single SSH keypair is fine. Some discussion of the question here:

* https://security.stackexchange.com/questions/40050/best-prac...

>On the other hand, passkeys are always associated with a single web service, never with multiple services, so that's an improvement in security over ssh keys and passwords.

Is it? I suppose that would be true if you didn't want the various services you use to know you were the same entity. That's more of an anonymity issue.

Then why does the passkey scheme even bother with public key cryptography? Why not just generate random passwords for each site and store those? This seems to be logically equivalent to a password manager.
Or the submitter posted wrong link?

https://news.ycombinator.com/item?id=35854475
Yeah unless you are designing the replacement for a system that has already reached it's scalability limits you shouldn't be worrying too much other than not doing very silly things architecturally.

When you are designing replacements though you need to have an idea of what your scalability runway is before the next re-design will be possible. Sometimes that is just 2x, often times it's 10x, occasionally it's 100x but it's all situational.
> so why allow it on the internet?

I find this weird also. The explanation I've been able to come up with is that there isn't prosecution on the internet the way that there is IRL. You're just screwed if you got hacked by someone whose VPN provider didn't already have a tap order in place on this customer. Without deterrence, the only remaining thing you can do is make it impossible to perform in the first place.
Are there any open source passkey implementations?

My password manager of choice is open source, and cross-platform, and can export and later (or elsewhere) import an encrypted backup.
> I think for a while we even had some sort of check that would detect a jailbroken iPhone or rooted Android device and attempted to refuse to run on them.

Your uncertainty about this suggests it's not something you decided, but please let anyone involved in making decisions like that know that's a dick move. It's the user's device, not the bank's.
Obviously, the article is microservice apologia, but...

> They were able to re-use most of their working code by combining it into a single long running microservice that is horizontally scaled using ECS...

No, it was no longer a microservice; it became a plain service, as in SOA. It was no longer micro. That's the whole point.

They could have saved time and money had they just made the thing a plain service to begin with. This thing was not sufficiently complicated to warrant the complexity of starting with a bunch of microservices.

The article says many hot takes have missed the point, but I think what we're seeing here is an example of the two sides talking past one another since the author hasn't appreciated the opposition's arguments at all.
Eh before the M1s I really disliked macs, and cursed that I had to use some at work. Even now I prefer AMD for desktop. But the unparallel energy efficiency of apple silicon for laptops is just a fact, and I will believe that AMD or intel can challenge apple in laptops when I see it, because till now they are hopelessly far away.
You can look beyond "popular", create something significantly better than current tech and then convince other actors to phase out all their existing chargers in favor of it.
For a while I hipstered out with a wax tablet*, but these days I'm back to a succession of boring A8 notebooks.

* https://en.wikipedia.org/wiki/Wax_tablet
I think I'm experiencing uncalled for government regulation. I would rather have no port change in the next 10 years. I'm not asking for change the EU is.
It's not about the activity, it's about the serendipity. There is no serendipity when you are working remotely.
You can set spend limits and limit warnings with OpenAI.
> It's crazy to me how much telephony still sucks.

I think about this every time I use make a voice call on a cellphone -- in terms of audio quality, it blows my mind how inferior it is to what we had on POTS lines in the 80s.
This site was a response to a very annoying practice in fashion during these years - people were writing full articles and websites in light grey font color.

My complains back then:
http://avodonosov.blogspot.com/2014/12/web-design-advice.htm...

https://news.ycombinator.com/item?id=8776744

Today I don't see this practiced. Strange to see the contrastrebellion on top of HN.
TOTP keys, written down, would probably be ideal for that.
Curious though, what is the reason for banning PHP? It must be pretty specific if they singled out just PHP.
> 1. Pixel phones display an "unlocked bootloader" warning (which can't be disabled)

Yet. Other manufacturers have the same warning and have had them disabled. (I did it to one of my older moto phones a few years back)

> 2. Unlocking does not void warranty.

Not by itself, but having a signal in place that it was unlocked lets the manufacturer look for common problems caused by doing things like flashing the wrong device images to critical partitions (go search around a bit for people corrupting EFS on their phones).

Critically Pixel devices do not have a debrick tool that's leaked, at least not for the Qualcomm-based Pixel devices. This means that a brick on any of those partitions means the phone needs a trip back to the depot or a service center that has these tools. Can't be fixed by end-user. Maybe this situation has changed for the Tensor/Samsung pixels but the point is screwing up your device due to flashing incorrect images shouldn't be something the manufacturer needs to foot the bill on.
Guess I'm only worried about it being used against me. Don't know enough about any threats it might enable.
Not using the STL in and of itself is not terrible advice, it's a trade-off. For example, I tend to avoid the STL because of how inconsistent it is across the various compilers in terms of performance, bugs, and behavior. The standard leaves a great deal of ambiguity in how the STL behaves and those inconsistencies can be frustrating to deal with when you're writing cross platform software. Furthermore plenty of embedded systems also cut out the STL entirely due to disabling exceptions. Using fast-math is also a perfectly acceptable option for numerous domains that do not need strict IEEE conformance, such as graphics programming or training neural networks.

If people were to listen to your advice, no one would ever post any kind of article on how to achieve certain specific goals, all we'd ever discuss are very generic topics and constantly rehash the same content over and over again. It's good to be able to learn how certain developers manage to accomplish various goals without having someone come along and call that advice terrible.
> Older people that eventually found good tools to solve problems have less time and enthusiasm to try new things. They still do but only when they think it's worth it. I'm there now.

The best thing about this phase is you just get so much shit done instead of screwing around with 10 half-baked over-marketed frameworks.
WebAuthn lets RPs reason about the strength and capabilities of the authenticator at registration time. With a mechanism like a shared file format and standard ways of transferring them, those mechanisms would be undermined. With hardware-backed multi-device Passkeys, the entire sync fabric becomes the authenticator. Apple and Google currently zero out attestation data, but you can imagine a scenario where attestation data matching the device is presented for single-device passkeys and DPK, but a different attestation key is used for multi-device passkeys that represents the entire sync fabric.

Instead, with all these password manager vendors not wanting to be left out, and a good portion of the userbase either not being entirely in a single vendor's ecosystem and not wanting to deal with the hassle of QR codes and registering each fabric in each RP, or simply distrusting the big vendors like we see here in this thread, I can see cross-platform virtual authenticators like the one you're working on becoming more common, and I don't think it's unlikely that the OSs will offer APIs to back these keys with TPMs/Secure Enclaves, and will allow you to replacethe built-in passkey manager with a third-party, much like they do with password managers today.

If software-based authenticators want to support import/export capabilities, they don't quite need an open standard, in the same way there isn't one for passwords but you can import/export passwords with any major password manager.
and most people i know in my apple bubble just don't really care and a number of them have lightning devices/docks and are not looking forward having to find/pay for replacements.

not gonna argue it isn't silly, it is, just that there is over a decade of lightning devices out there that will now become e-waste and good chance apple was trying to avoid taking the heat for forcing the change onto users. Now they get to blame the EU.

devices like https://www.flir.com/products/flir-one-gen-3/ - a 200$ device - will now have to be replaced when moving to the usb-c iphone.
V8 provides a JS runtime.

Node uses the V8 C++ APIs to add additional functions and objects to that runtime.

So Node has a specific JS runtime environment, just as browsers have a specific JS runtime environment (and Workers have another), etc.

All of these environments are extending the runtime environment provided by their underlying JS runtime, they're not all providing their own stdlib implementations, they're not providing their own implementations of arrays, objects, global object, etc.
Xiaomi heavily subsidizes their phones. The idea is that they make it back with people using their apps.
Source on Microsoft employees seeing everything I write in "Microsoft Office"? Not 365, but local docx
>Lose your (google) passkeys account for whatever reason (ai says no, wrongthink, itar ban), and you risk losing your digital life.

Isn't this entirely orthogonal to the usage of passkeys? You could "lose your digital life" if you forgot your password, or remembered your password but tripped their risk scoring system (eg. fresh login from an unusual location).
If by any chance you haven't seen the movie — please, do. There's a reason it became a cult classic and a lot of people watch and re-watch it many, many times.
No. Do you know much about TEPCO?
I think Cloud Run, Fargate and Azure Container Apps all fall more into the category of "platform-as-a-service" rather than "function-as-a-service", in the same way that EKS or GKE could be categorised as a PAAS.

EDIT: I also think they're _excellent_ to use for development. The migration from ECS + Fargate to EKS + EC2 is not a difficult migration from the application side, and can be done relatively piecemeal, in my experience.
Yeah, I'm not pro-EU but the bloc was originally a Coal and Steel trading pact. It expanded from there as deeper integration became advantageous.
I don’t think it’s a complete downgrade. You get phishing protections, single-site super-strong “passwords”, if the public key is leaked, it doesn’t impact you, etc.

If the only attack vector is someone having to crack into your encrypted hard drive, and then decrypt whatever stores the passkeys… that’s still both pretty strong and also probably not the biggest security issue most people face.

The biggest issues most non-tech people face are 1. reusing simple passwords, and 2. getting phished through similar UIs/emails. It’d be much better for most people to use passkeys.
The rise and changing role of Chief Product Officers
The Apple security model for Apple ID and iCloud already works like this. Every device is effectively a “passkey” even if they don’t call it that. Been that way for a while now.

Every device (except accessories like AppleTV, HomePod, etc.) you log into iCloud with effectively has Super Admin control over your entire iCloud account. Any logged-in device can remove, modify, or change (almost) anything without a password… including the account password (hence the almost). Once authorized, that access is controlled by biometrics with a backup PIN. As long as you maintain control of a single device you have access to everything.

Yubikeys work the same way. Doubly so when dealing with resident credentials and passkeys. Key as as many as possible—just make sure the PIN is not obvious. If you hold the key and know the PIN, you can do anything. No other information is needed.

The big difference between this and OTP is two fold: 1) much more resistant against phishing; and 2) the underlying key is less likely (or impossible-ish) to be exposed. Phishing a 2FA OTP is actually not hard with a good fake UI. It just requires someone to act quickly on the other end or a good script that can quickly change the password/security settings once a password and OTP are successfully phished.
> The M40 does not support 4bit, so it's basically useless for LLMs.

Good to know, thanks !
"no, no, but NEXT time will be different!" said the fairy tale.
Online backup stuck inside Google's walls is the opposite of spreading my risk.

An offline backup I can control, I can put in a safe for my relatives in case I die unexpectedly. Or I am robbed. Or any number of foreseeable circumstances where the physical manifestation of my secret is lost.
Nothing breaks in fun or interesting ways. All that happens is std::terminate is called.
Title seems to have been invented by the youtube uploader, and TEDx is incorrect: this was an actual TED talk.
I have pg's list of nine Lisp ideas [1]. What of these are missing in Janet? My guess is that only 9th one but I would like to understand Lisp (any) vs Janet point.

[1] www.paulgraham.com/diff.html
FWIW I once got super high from a bottler. So high that I suspected it was either over dosed or even not LSD. I sent a similar one for analysis. Turned out it was pure LSD and about 125mg as advertised.
A lot of people in the world only have one primary digital device - a phone. If that phone breaks, or is lost or stolen, how do those users get back access to their keys? Will the store holders like Google and Apple validate their identity w/ personal information frequently stolen from credit agencies and healthcare industry data stores?
Adding to this, I just don't see the use case for "smart" devices. The difference between me getting up and checking the thermometer vs checking the thermometer using my phone is 10 seconds, max.
This is tricky. With enough people, yes, a number will survive battle wounds. Most people died, though.

Consider, 50 to 70 million deaths in WW2. And that isn't looking at more genocidal like methods earlier humanity almost certainly used. Numbers would be lower, but percentage higher.

Yes, we are resilient, but that has limits. And is mostly overcome by having more kids.
The EU is the final arbiter. Top phone companies all agreeing on a new standard does not change the regulation. And even so, that just sounds like regulatory capture.