No RAM. Instead of having a general purpose multiplier that multiplies an input with a weight stored in RAM, just have a multiplier that hardcodes the weight. In some sense replace each weight with a specialized multiplier and wire them together with accumulators and activation functions in between. And some registers for pipelining. If one goes for four bit quantization, one could have sixteen optimized multipliers, one for each possible weight, and the one just selects and connects them according to the model weights and structure.
Example. If you have a neuron with 16 inputs each 8 bit wide and with a 4 bit weight per input, you will have 16 specialized multipliers each scaling its input by the corresponding weight and then the 16 scaled inputs feed into an adder tree and finally an activation function.
That sounds like wiring the RAM information into order of magnitude same number of transistors. A modern CPU has (quick googling) 184B transistors. If they were bits then that's 23GB. But presumably a model bit needs more than one transistor to represent how it acts as a neuron with its interactions.
Then there's the current speedup in inference from restricting which subset of the model is used, which is not a "swap in" that would work with hard wired neurons.
An employer making career-affecting decisions for their employees based on whether they have kids or not sounds like a great way to get sued.
That said, I have been asked if I had kids, in an interview. Later in my career, when I was trained to perform interviews, I was explicitly told to NEEEEEVER ask that. And if the candidate volunteers it, to basically pretend you didn't hear it.
When I read commit history I want to see the reasons. Commit messages are for extra context.
It's very useful if it says AI/LLM was used, then I know that there may not actually be a reason for the choice in the commit, so per Chesterton's fence I can then tear down that fence.
Now, do I need to know which brand of LLM? No. And fair enough, I'll stop being specific.
Are you talking about the goal being bad, or the methods being bad, or that the goal inherently cannot be achieved without bad methods?
E.g. I think something pretty uncontroversial would be a goal of blocking kids from the likes of TikTok & Instagram between 22:00 and 08:00.[1] But if I'm an adult, that's a different matter. Ok, so how do I prove I'm an adult, without society turning into a surveillance state, or surveillance capitalism?
Next up: wouldn't it be nice if e.g. someone over the age of 30 couldn't initiate chats (including comments on posts) with 13 year olds? For hobby exceptions (e.g. joining a computer or chess club) it would make sense to either have parental approval, or some moderation requirements for parental approval exempt groups.
[1] I'm here not saying that this is the biggest problem, but it should at least be uncontroversial.
The goal is good. Like i said, i think those kinds of social networks are evil and their executives should be jailed.
That being said, the methods are really bad. Are they efficient? No. Kids can still access discord despite age verification. And some kids can still max out their parent's credit card despite not being old enough to own a bank account.
Do those methods produce other net negatives? Yes. Standardizing digital identity leads us one step closer to dystopian nightmares from sci-fi books.
Are there better alternatives? Yes. Jail the CEOs. And if your government is too corrupt for that, they could at the very least raise awareness. Governments didn't have to mandate fingerprint readers on cigarettes to fight smoking. They found other ways and there are less kids smoking now than in the previous generation. Also, they could still jail the tobacco CEOs who lied publicly (and under oath) for decades.
Any time someone builds a social network, they'll be equally liable for any danger for kids that result? De facto making social networks illegal?
Or is a moral/legal social network possible? If so, then it seems we're talking about two different things: 1. jail the CEOs of these companies… for… something (it's unclear to me. Not that I disagree, but you've not made the case). 2. How can we make social networks "a good"?
Surely you can't mean banning all social networks, because HN is a kind of social network.
What is an evil "kind" of social network? "I know it when I see it"?
I'm not sure that's step one. But at least it's a good selling point to say we can do something very quickly about that problem, and almost everybody agrees (except for a few tech bros and every government on the planet). Step one is taking back control: empowering alternatives, providing free psychological services for the people who've been harmed by Facebook & such, seizing all the money they have defrauded via tax evasion (double irish sandwich), etc...
And if society wants to put people on trial, don't forget to put the engineers up there. The CEOs/managers may give orders but the engineers also have personal responsibility. They knew what they were doing (a few spoke out), and they certainly make sure their own kids don't use their own products. Technology is not neutral, and following orders is not an excuse for cruelty (see also, Nuremberg trials).
> De facto making social networks illegal?
I think there's a margin for interpretation, though i'm neither a lawyer nor a judge. A few criteria which may already be illegal, to determine whether a social network is evil:
- leading and using research on attention/addiction to keep people hooked
- having platform-controlled advertisement (an incentive to keep people captive)
- having posts on "your" feed not determined by your own subscriptions, but by an opaque algorithm where the platform decides what you see
- mandating a civil identity to join the social network (sometimes even requiring users to submit an ID card), which was promoted 15 years ago as an anti-harassment measure but actually had the exact opposite effect
That's just a few criteria that came to mind. We can probably find more. HN, a mailing list or a forum fills exactly 0 of these criteria.
> What is an evil "kind" of social network? "I know it when I see it"?
I'm not sure. But i'm sure we as a society need to think about it, because the neo-fascist tech-bros running those social networks certainly have.
Imagine buying a luxury car and finding the manufacturer saved like $10 on the very thing you interface with every single time you drive all the time, making the overall experience absolute shit.
"Can I pay you the $10 and you make my car not shit?" — "No, I'm sorry, we only make shit now".
Yes, with TPM and yubikey you have the option to store the per key material on disk, encrypted by the TPM. But the way this is then used is that the PKCS software sends that encrypted blob AND the requested operation, and gets only the output back. The CPU doesn't get the SSH private key back. Just the output of the RSA operation using the key.
Depending on which authenticator app (or maybe applies to all?), that data either is, or can be, backed up.
A yubikey cannot be cloned.[1]
> the malware rides along this expectation and gets ahold of your private SSH keys and stores them or sends them off somewhere.
Ah, this is where your misunderstanding lies. No, the crypto operation runs ON the TPM or yubikey. The actual secret key NEVER lives in RAM. (ehem, after it was imported, if importing is the method by which it was generated)
[1] You know what I mean. Of course in principle it can be. But not like a phone where it can literally be sent via scp.
This assumes that the server is running a recent enough OpenSSH. Configured with this enabled. For Linux servers, sure. For routers, less obviously so.
Yeah but more importantly neither will those multi million dollar routers your ISP uses. Nor their ten thousand thousand dollar switches.
And they won't be replacing these just because they're missing FIDO. And they can't "just" be upgraded because they aren't necessarily just Linux boxes in a trenchcoat. Nor are they necessarily running any version of OpenSSH.
Without presence test (e.g. yubikeys touch) it's certainly not perfect. But it does close some real world attacks. Like the key can only be used while your laptop is on. (assuming laptop, here).
And keys cannot be stolen from backups.
Or stolen without your knowledge when you left your laptop unguarded for 5min.
Not every attacker has persistent undetected access. If the key can be copied then there's no opportunity for the original machine's tripwires to be triggered by its use. Every second malware runs is a risk of it being detected. Not so, or not in the same way, with a copied key.
Android actually supports secure transaction confirmation on Pixel devices using a secure second OS that can temporarily take control of the screen and volume button as secure input and output! https://android-developers.googleblog.com/2018/10/android-pr...
This is really cool and goes beyond the usual steps of securing the key, but handling "what you see is what you sign" and key usage user confirmation at the OS level, which can be compromised much more easily (both input and output).
Quote: "Android Protected Confirmation is deprecated due to the high
support/maintenance cost for Android device makers and low adoption rate
among app developers. APC requires Android device makers to have a
substantial amount of device-specific UI code running in the trusted
execution environment. That has proven to be expensive to maintain and
non-scalable, as there cannot be a single implementations device makers
can share or use as a reference. Additionally, app developers have not
adopted this feature, as the Android platform offers other mechanisms
for authentication a user's intent. These mechanisms, such as
authentication-bound Keystore keys, are less secure than Trusted UI, but
are more wide-spread. While we explore alternatives to APC that are
viable to the device makers ecosystem, we sunset the APC API."
Oh damn, I missed that, thank you. I could see how it was a very expensive thing to maintain for an effectively Pixel-only feature.
Still, I think this was one of the most ambitious and user-beneficial implementations of trusted computing I've seen so far, in that it theoretically safely allows a completely rooted/user-owned device to still participate in things like online banking or e-government transaction authorization. I hope it'll return in some form.
Yes. But that'd just be a TPM on a computer, in hand held form.
A laptop and a phone are both general purpose computers with "TPM chips", so "you could implement that on android" is as true as "you could implement that on a white computer".
There was something about Macs. It took them a while to get a TPM. But I think now they do, so macs can do it too.
Ah, I guess by "that" you meant the touch part, not the uncopiable part.
There are many ways to implement this. I think some Chromebooks have FIDO gated on a physical button.
If you have an unlocked device with keys usable requiring a mere touch, I'm not sure fingerprint adds much value. A button would be enough.
Actually checking with fingerprint only addresses an extremely narrow attack where someone who wants to attack you steals your device (so already physical access, meaning not DPRK hackers) while it's unlocked, and only getting a window of opportunity until you've called your security department to lock your account.
… and yet this attacker would NOT be willing to use force against your person, to make you use your fingerprint.
Sure, if that's a threat model that's worth your time, use fingerprint too.
Keep in mind that already going from software only (and arguably this includes OTP app on your phone) already means effectively going to zero. Google moved to security keys and says “We have had no reported or confirmed account takeovers since implementing security keys at Google” — https://krebsonsecurity.com/2018/07/google-security-keys-neu...
So there are extreme diminishing returns after just security key with touch.
An app solution even gets a callout in that article as being not as good.
RAM is really slow at silicon speeds. Very little is reachable in one clock cycle, unless the clock cycle is abysmally slow.
reply