Okay, then I set the date on my computer to year the 2124. Now the DRM is unlocked!
You can't build a "time lock" with just encryption primitives. Even if you could build a time lock with just encryption primitives, we don't know when the copyright will expire until the original author has died, since copyright term is life + 70 years.
Someone would have to run a server that specifically chooses to start serving the keys on that date, which is an absurd notion given how absurdly long copyright lasts these days.
If the federal government were interested in passing a law that required this, I'm sure the Library of Congress could run such a server, but no such law exists.
> set the date on my computer to year the 2124. Now the DRM is unlocked!
It's the same. "Fail closed" means you can "just" set the system time to be before the expiration date, "fail open" means you can just set the system time to be after.
Either way, having an expiring decryption key is just security theater that harms users.
Maybe not through crypto but otherwise perfectly achievable. No reason to achieve this within a file. If you really want to, some fancy solution involving blockchains and smart contracts is probably possible but there is no need.
Require by law all who desire copyright protection to register the work with a governmental agency and place a copy of the work in escrow at an archive as a condition. The archive knows when the copyright expires and starts serving the work to the public from that point forward. This is what to do if a state cares about public domain.
The status quo of corporations abandoning works to bit rot, actual rot, misplacement or fires for decades is strictly worse.
>> If the federal government were interested in passing a law that required this, I'm sure the Library of Congress could run such a server, but no such law exists.
> Require by law all who desire copyright protection to register the work with a governmental agency and place a copy of the work in escrow at an archive as a condition.
You’re just repeating what I already wrote. By all means, call your representatives.
No need to spoof the GPS signal, pop open the lid and replace the GPS chip with one that outputs an attacker-controlled time signal. I suppose it could encrypt this signal with some certificate burned into the silicon, but that could still (slowly and painfully) be reverse-engineered.
GP’s point stands, you can’t enforce a time lock with cryptography primitives. That’s the fundamental issue with DRM - you’re trying to restrict someone from getting your ciphertext, while at the same time allowing them to get to it if they meet certain (non-cryptographic) conditions, which standard cryptography just can’t do.
Given the number of “personal wiki” applications that exist, and the conceptual viability of it (a Wikipedia-like maintained by a single person for solely their own usage — a wiki representing their own knowledge base — is perfectly sensible), I find this definition to be excessively constrained.
And from that webster’s definition, roughly any site with user comments can be called a wiki. If you change the OR to an AND, the only thing stopping HN from being a wiki is the “corrections” component — which definitely does not correctly capture the difference between the two.
Wikipedia’s definition is also awkwardly constrained — hypertext and web browsers are obviously just an artifact of current implementations; if you managed it through markdown files and an app, does it seize to be a wiki? Is an offline read-only dump of Wikipedia passed around on a USB by bicycle no longer a wiki?
> Given the number of “personal wiki” applications that exist [...] Wikipedia’s definition is also awkwardly constrained
It's neither awkward nor overly constrained. It's just defining what a wiki actually is.
I find the questions at the end of your comment strange; they have correct answers that you'd probably find surprising, given the fact that you're asking in a way that suggests you think constitutes a sound argument for your side. For example, your last one:
> Is an offline read-only dump of Wikipedia passed around on a USB by bicycle no longer a wiki?
Uh, yes? Wikipedia remains a wiki, certainly. Your offline dump of it is not. What you have there is an encyclopedia. And that exemplifies what's really at issue.
The word "wiki" being thrown around inappropriately is the product of shallow thinking about wikis, encyclopedias, and the relationship between the two. People who are in the audience for the tools described here and that you are talking about are simply not talking about wikis.
These people are not building a personal wiki—they're building a personal encyclopedia. That's what they're doing. An "encyclopedia of me". But because of a failure to grok how portmanteaus work and likely their only exposure to wikis being through Wikipedia, they have a debased understanding of what the "wiki" part of Wikipedia denotes. (Or perhaps they just think "wiki" sounds cooler than the far less hip suffix -pedia, and so they have contorted their thinking and their arguments around trying to defend saying one instead of the other at the expense of the rest of the world—the "I missed my turn, but that's okay, I'll just make everyone around me pay for it"-style of thinking.)
It's like if you lived your whole life in a part of the world where iced coffee isn't consumed (and other types of coffee only rarely), then when it's introduced to your people it's to great fanfare, and for no good reason a subset of your countrymen start calling all sorts of unrelated things "ice", whether ice is involved or not. Their sole motivation? The thing they're referring to is a coffee product. So someone asks, "Have you checked out the ice?" — at a diner where the only type of coffee comes poured from a pot of the hot stuff. "We're really getting into icemaking" — after having just bought a new countertop espresso machine. "I got some ice candies from Barter Jack's" — referring to chocolate-covered coffee beans.
> does it seize to be [...]?
The correct word is "cease", but I suppose you'd argue that that's overly prescriptive and a constraint that needs changing, too.
2FA was not created as a defense against password manager compromise. That is not its purpose. It protects against password reuse attacks and helps to protect against total compromise of people who have been phished.
Even better, a password manager can avoid giving up a TOTP code to a phisher in the first place because it is checking the domain.
If your password manager is compromised, you’ve got big problems regardless of 2FA tokens being in there or not.
The extremely marginal security benefit of storing the 2FA tokens separate from your password manager is just not even worth discussing in most scenarios. It exists, but doing that causes the additional risks of losing access to your 2FA token or having your 2FA code phished, both of which seem a lot more likely than your password manager being compromised. At least, as long as you’re using any halfway decent password manager.
Long term, the goal is to get rid of passwords and 2FA altogether by switching to Passkeys. Each Passkey will naturally be stored in a single place, since they can’t be split into multiple parts anyways.
It's important to think about threat vectors. A general concept like "the password manager getting compromised" is not really a threat vector, it's more the outcome of a threat vector. How exactly do you think a password manager is getting compromised? To identify the threat vector, we need to talk about the actual method of compromise here.
A 1Password vault is fully encrypted and protected by several layers of security. The most important layer of protection: the 1Password vault is encrypted with a combination of your password and your Secret Key[0], which is a long key generated uniquely for each vault. Even with a weak password, the vault has very strong encryption because of the Secret Key, which you don't get the opportunity to mess up and make weak by accident. Without both, the Vault cannot be decrypted, and nothing is stored in plain text; everything is stored in the encrypted vault. An additional layer of security is that they can't even get the vault from 1Password's servers without both your password and a second factor, assuming 1Password hasn't been compromised, but this is not critical. Even if the attacker got their hands on the vault, the vault itself is very secure. No attacker is going to be able to brute force the encryption key.
The most likely way (probably the only realistic way) for a well-secured password manager to be compromised is for someone to gain access to your machine while your password manager is unlocked. A simple keylogger is not enough, since it won't capture your Secret Key unless this machine has been deeply compromised since the day you set up 1Password on it for the first time. But, even then... that would mean they already own your machine.
So, total access to your fully unlocked machine, with your password manager also unlocked. That's what password manager compromise means in this context, at least to me. Remote access or physical access, it doesn't matter. As I said in my previous comment, if they have access to your password manager, "you've got big problems", because they probably have access to a lot more than just your password manager. If they have access to your machine, and your password manager is unlocked at the same time, it's game over for virtually anyone at that point.
It doesn't matter if the 2FA tokens are in there or not. It doesn't even matter if the passwords are stored in there, although I'm sure they wouldn't complain about having access to the passwords. Most services will allow the threat actor to reset your 2FA token (and password) simply by requesting a reset email with a verification link. Since the threat actor already has access to your machine, they almost certainly have access to your email, which the vast majority of people leave signed in. The password manager contains the username you use for each service, which is all they need to start firing off reset emails.
A very few websites won't let you reset your 2FA token, of course, but it's much fewer than the number of websites with 2FA. Anything other than verification emails (or never letting you sign in again) is very expensive for a website operator. Plus, what are the odds that you're not already signed into those sensitive services on this compromised machine? They may not even need your 2FA for whatever they're trying to do here. They own your machine. In the absolute worst case scenario (for the attacker), they just leave a RAT (remote access trojan) on your machine and walk away. They would just wait for you to sign into whatever they need, while you're completely oblivious to the attack. The password manager is an irrelevance.
The thing is... very few people get compromised this way in the first place. It's not worth losing sleep over unless you need to protect some extremely important asset. Certificate Authorities lose sleep over these kinds of threat vectors when it comes to their root signing key, of course.
I suppose we could also say something something quantum computers? Maybe some three-letter government agency can unlock your encrypted vault by waving a magic wand over it? If that's the threat vector you're worried about, then I don't think storing the 2FA tokens in a separate app is likely to help very much, but I guess it's something.
Even in my first comment, I admitted that there can be a very marginal increase in security by keeping your 2FA tokens separate from your passwords, so it can be the correct thing for certain scenarios. But, it does present additional risks, especially for TOTP. For those scenarios, I would generally recommend a YubiKey and using U2F instead of a TOTP app on a phone. For your security to be better off by keeping 2FA tokens out of the password manager, I believe that you need to be implementing some extreme security practices all over the place. Otherwise, it won't matter. Your password manager should be an extremely secure place to store 2FA tokens. If it isn't, then you need to find a better password manager ASAP.
Perhaps there are some other ways a good password manager could be compromised that I haven't considered in this comment, but those methods seem like they would have to involve either serious design flaws in the encryption or a big wrench[1]. You can never be 100% sure about any particular implementation of encryption, but what are the odds that someone is going to burn a very expensive zero-day exploit on you specifically? If they would do that, why? If there is a single service, or a single certificate, that needs the utmost protection, then yes, you need to take unusual steps to guard it. But this does not apply to almost anyone.
> What would be a realistic scenario? If I'm using a password manager, it won't recognize the phishing domain, which means I won't get to the 2FA step.
Usually, someone receives an important-looking email that calls them to take action by clicking a link. They urgently click the link, and begin trying to sign in. If it is being done by a threat actor who has already compromised your password by another means, they would just skip straight to the 2FA token prompt.
But, considering how skeptical that person sounded of password managers in general, I wouldn't be surprised if they're the kind of person who avoids password managers for their "most important" accounts anyways. Instead, choosing to use (relatively weak) memorized password(s). So, then they get phished for their memorized password, then reach for their "secure" separate 2FA app, and a 2FA code gets phished that way too. Game over.
Similarly, I think it is important to provide an “|” grammar that defines an error response, and explain to the model that it should use that format to explain why it cannot complete the requested operation if it runs into something invalid.
Otherwise, it is forced to always provide a gibberish success response that you likely won’t catch.
I’ve tested this with Mixtral, and it seems capable of deciding between the normal response and error response based on the validity of the data passed in with the request. I’m sure it can still generate gibberish in the required success response format, but I never actually saw it do that in my limited testing, and it is much less likely when the model has an escape hatch.
Can you elaborate? So you instruct the model to either follow the grammar OR say why it can't do that? But the model has no idea this grammar exists (you can tell it the schema but the model doesn't know its tokens are going through a logprobs modification).
No, the grammar can do OR statements. You provide two grammars, essentially. You always want to tell the model about the expected response formats, so that it can provide the best response it can, even though you’re forcing it to fit the grammar anyways.
In JSON Schema, you can do a “oneOf” between two types. You can easily convert a JSON Schema into the grammar that llama.cpp expects. One of the types would be the success response, the other type would be an error response, such as a JSON object containing only the field “ErrorResponse”, which is required to be a string, which you explain to the model that this is used to provide an explanation for why it cannot complete the request. It will literally fill in an explanation when it runs into troublesome data, at least in my experience.
Then the model can “choose” which type to respond with, and the grammar will allow either.
If everything makes sense, the model should provide the successful response you’re requesting, otherwise it can let you know something weird is going on by responding with an error.
> Then the model can “choose” which type to respond with, and the grammar will allow either.
Ah I see. So you give the entire "monadic" grammar to the LLM, both as a `grammar` argument and as part of the prompt so it knows the "can't do that" option exists.
I'm aware of the "OR" statements in grammar (my original comment uses that). In my experience though, small models quickly get confused when you add extra layers to the JSON schema.
I wouldn’t provide the grammar itself directly, since I feel like the models probably haven’t seen much of that kind of grammar during training, but just JSON examples of what success and error look like, as well as an explanation of the task. The model will need to generate JSON (at least with the grammar I’ve been providing), so seeing JSON examples seems beneficial.
But, this is all very new stuff, so certainly worth experimenting with all sorts of different approaches.
As far as small models getting confused, I’ve only really tested this with Mixtral, but it’s entirely possible that regular Mistral or other small models would get confused… more things I would like to get around to testing.
I've tested giving the JSON schema to the model (bigger ones can handle multi-layer schemas) __without__ grammar and it was still able to generate the correct answer. To me it feels more natural than grammar enforcement because the model stays in its "happy place". I then sometimes add the grammar on top to guarantee the desired output structure.
This is obviously not efficient because the model has to process many more tokens at each interaction, and its context window gets full quicker as well. I wonder if others have found better solutions.
In the context of this thread, I believe even a digital computer would have to be rebuilt if the program is wrong... :P
Unless you typically salvage digital computers from the wreckage of a failed rocket test and stick it in the next prototype. If the FCC is wrong, kaboom.
Presumably they meant a program being discovered to be wrong before the computer was actually launched. And meant literally building a whole new computer, not just recompiling a program.
For the Apollo Guidance Computer, changing the program meant manually re-weaving wires through or around tiny magnet rings. A good part of the cost of the computer was the time spent painstakingly weaving the wires to store the program.
Pardon me, but why would you have to re-weave wires around magnetic rings? The magnetic rings are for storing data; the whole point is that you can change the data without rewiring the memory. If you have to re-wire permanent storage (e.g. program storage), that's equivalent to creating a mask ROM, which is basically just two funny-shaped sheets of conductor. There's no need for magnetic rings.
Only if the bug was caught after the computer had been assembled for the mission. For development, they used a simulator. Basically, a cable connected to a mainframe, with the bigger computer simulating the signals a bundle of core rope would produce.
Yeah, though to be fair, some of the programs Apollo ran were on hand woven ROMs, so I may be making too fine a distinction. The program itself was built, not compiled. It if we are comparing with today, it would just be installed, not constructed.
I had assumed it meant more simple things like balanced balancing pneumatic or mechanical components that always put you at the the correct ratio sort of like a carburetor vs fuel injection.
> (1) You pay for Prime. (2) You pay extra for Prime Video. (3) You now pay even more extra for Prime Video to not show you ads.
There is no triple dipping occurring here. Prime Video is included with the normal Prime membership under (1). So, (1) and (3) are true, but (2) isn't. I believe you can buy Prime Video (2) separately from Prime (1), if you don't want to pay the full price required for an Amazon Prime membership (1), but if you have (1), you don't pay extra for (2).
I've googled this just now, and I'm pretty sure about what I wrote above.
I would definitely complain about (3) too, but I think it's important to be accurate in the complaint.
If you're asking ChatGPT about its own characteristics, you should not believe the responses. Models can't examine themselves, so unless the model was trained on specific information about itself, or unless the info is put into the System Prompt, then it cannot know the answer. A response indicating 4096 tokens would just be a hallucination, or a misunderstanding based on training data that saw references to what older versions of ChatGPT were trained on.
ChatGPT-4 is powered by GPT-4 Turbo at this point, so it has a context window that is much larger than 4096 tokens, whether it knows it or not. The ChatGPT application may limit the context size from reaching the full 128k to keep costs down, and it will be using some of the context window for its own purposes, but it's certainly able to maintain context across more than 4096 tokens of conversation.
It’s just running bog standard Llama2-70B by all appearances.
I don’t know why so many people here are interested in the outputs. The whole point of this demo is that the company is trying to show off how fast their hardware could host one of your models, not the model itself.
I assume it queues up requests if there are too many in flight to handle all of them at the same time, but it shows you the tokens per second (T/s) for every response, which is the number that matters (and presumably won't include the time spent in the queue).
You can be confused by why people are interested in the outputs, or you can think that the explanation is adequate. You can't do both at once.
Here, in fact, the explanation is not adequate. Let's analyze:
> Welcome Groq® Prompster! Are you ready to experience the world's fastest Large Language Model (LLM)?
"The world's fastest LLM? They must have made an LLM, I guess"
> We'd suggest asking about a piece of history, requesting a recipe for the holiday season, or copy and pasting in some text to be translated; "Make it French."
"Instructions, ok".
> This alpha demo lets you experience ultra-low latency performance using the foundational LLM, Llama 2, 70B created by Meta AI - running on Groq.
"So it's not their own LLM? It's just LLaMa? What's interesting about that? And what's Groq, the thing this is 'running on'? The website? I kind of guessed that, by virtue of being here."
> Like any AI demo, accuracy, correctness, or appropriateness cannot be guaranteed.
"Ok, sure".
Nowhere does it say "we've built new, very fast processing hardware for LLMs. Here's a demo a bog-standard LLM, LLaMa 70B, running on our hardware. Notice how fast it is".
There is quite literally a modal pop-up that explains it, which you must dismiss before you can begin interacting with the demo. Quoting the pop-up: "This alpha demo lets you experience ultra-low latency performance using the foundational LLM, Llama 2, 70B created by Meta AI - running on Groq."
Towards the bottom of the page, it also says "Model: Llama 2 70B/4096".
Below that, it says "This is a Llama2-based chatbot."
I posted this here, but it somehow moved, and I can't delete that one, so I'll repost.
You can be wonder why people are interested in the outputs, or you can think that the explanation is adequate. You can't do both at once.
Here, in fact, the explanation is not adequate. Let's analyze:
> Welcome Groq® Prompster! Are you ready to experience the world's fastest Large Language Model (LLM)?
"The world's fastest LLM? They must have made an LLM, I guess"
> We'd suggest asking about a piece of history, requesting a recipe for the holiday season, or copy and pasting in some text to be translated; "Make it French."
"Instructions, ok".
> This alpha demo lets you experience ultra-low latency performance using the foundational LLM, Llama 2, 70B created by Meta AI - running on Groq.
"So it's not their own LLM? It's just LLaMa? What's interesting about that? And what's Groq, the thing this is 'running on'? The website? I kind of guessed that, by virtue of being here."
> Like any AI demo, accuracy, correctness, or appropriateness cannot be guaranteed.
"Ok, sure".
Nowhere does it say "we've built new, very fast processing hardware for LLMs. Here's a demo a bog-standard LLM, LLaMa 70B, running on our hardware. Notice how fast it is".
You can't build a "time lock" with just encryption primitives. Even if you could build a time lock with just encryption primitives, we don't know when the copyright will expire until the original author has died, since copyright term is life + 70 years.
Someone would have to run a server that specifically chooses to start serving the keys on that date, which is an absurd notion given how absurdly long copyright lasts these days.
If the federal government were interested in passing a law that required this, I'm sure the Library of Congress could run such a server, but no such law exists.