• 1 Post
  • 449 Comments
Joined 1 year ago
cake
Cake day: July 14th, 2023

help-circle
  • In AD&D, you still had access to the abilities of your retired classes, but if you used them you had experience penalties (if you use them in an encounter, you gain no experience for that encounter and your experience for the entire adventure is halved) . The reason was that you were supposed to be learning to do things a new way, and if you fell back to the old way, you weren’t pushing yourself anymore. From the AD&D PHB, under “Dual-Class Benefits and Restrictions”:

    This is not to imply that a dual-class human forgets every-thing he knew before; he still has, at his fingertips, all the know-ledge, abilities, and proficiencies of his old class. But if he uses any of his previous class’s abilities during an encounter, he earns no experience for that encounter and only half experi-ence for the adventure.

    The paragraph goes on to explain what’s restricted (everything but HD and hit points), then ends with:

    (The character is trying to learn new ways to do things; by slipping back to his old meth-ods, he has set back his learning in his new character class.)


  • Sorta turns the AD&D mechanic on its head. And it makes more sense than the way it was done in AD&D - I like it!

    Context: in AD&D, humans could “dual class,” which is similar to what you described - effectively retiring in one class and beginning to advance in another - and non-humans could “multi-class,” where they gained experience in two or more classes at the same time, leveling more slowly but getting the benefits of both classes.



  • hedgehog@ttrpg.networktoRPGMemes @ttrpg.networkRespect the hustle
    link
    fedilink
    arrow-up
    2
    arrow-down
    1
    ·
    1 month ago

    Damage taken from being the Fall season would be called “Fall damage” in English though.

    If I’m in a fight, I’m fighting. If I’m on a walk, I’m walking. On a hike? Hiking. If I’m at a party, I’m partying. If there’s rain in the air, it’s raining. If I’m applying butter to my toast, I’m buttering my toast. If I’m on a boat, I’m boating. If I’m in the middle of a fall, I’m falling.

    Is it hard to understand that someone is referring to the act of entering Fall (or being in the middle of Fall) when they call it “falling?”

    Regardless of whether you find that difficult to understand or to accept, it’s a well-established linguistic phenomenon known as “verbification.”

    You are not falling. It is fall. Falling is only from a present tense verb of fall.

    You’re wrong on several counts.

    First, you don’t suffer “falling damage” from falling. You suffer it from landing after falling (refer to page 183 of the PHB if you don’t believe me). However, casting Feather Fall is a reaction that you can take when you or another creature “falls,” so it was appropriate to cast it at the start of the season.

    Second, “falling” is not the present tense of “fall.” The simple present tense of “fall” is “fall” or “falls,” but other “present tenses” include: the present perfect simple (“He has fallen”), present progressive/continuous, and present perfect progressive.

    “Falling” is the present participle, and it can be used both as an adjective (“The falling bard”) and as part of the past continuous/progress (“The bard was falling”), present continuous/progressive (“The bard is falling”), and future continuous/progressive (“The bard will be falling”) verb tenses, as well as with their perfect variants (had been falling, has been falling, will have been falling).






  • Yes, but only in very limited circumstances. If you:

    1. fork a private repo with commit A into another private repo
    2. add commit B in your fork
    3. someone makes the original repo public
    4. You add commit C to the still private fork

    then commits A and B are publicly visible, but commit C is not.

    Per the linked Github docs:

    If a public repository is made private, its public forks are split off into a new network.

    Modifying the above situation to start with a public repo:

    1. fork a public repository that has commit A
    2. make commit B in your fork
    3. You delete your fork

    Commit B remains visible.

    A version of this where step 3 is to take the fork private isn’t feasible because you can’t take a fork private - you have to duplicate the repo. And duplicated repos aren’t part of the same repository network in the way that forks are, so the same situation wouldn’t apply.



  • It sounds like they want a representative sample, which isn’t something I’d be confident in my ability to help them with directly, so I’d advise them to first scan for a person who’s very experienced in statistical sampling and to then work with that person to determine a strategy that will meet their goals.

    If they weren’t on board with that plan, then I’d see if they were willing to share their target sample size. If I didn’t have an option for the count I would assume they would be contacting 1% of the population (80 million people). I’d also let them know that being representative and selecting for traits that will make encounters go smoothly are conflicting goals, so I’m prioritizing for representation and they can figure out the “please don’t pull a shotgun out, human!” trait on their own. Depending on all that, I’d recommend an approach that accounted for as much of the following as possible.

    • gender (male, female, non-binary)
    • race
    • culture and sub-culture (so this would include everything from religion to music to hobbies)
    • profession
    • age, broken down into micro-generations
    • mix of neurotypical and neurodivergent
    • different varieties of neurodivergence
    • range of intelligences

  • But being rude and abusive to support staff doesn’t help, encourage, or even compel the support staff do their jobs any better or faster. In fact, I’d wager it’s rather the opposite.

    I work in IT (not IT support, though) and I’m fortunate enough that none of my business partners are outright abusive. Even so, I still have some that I deprioritize compared to others because working with them is a pain (things like asking for project proposals to solve X problem and never having money to fund them). If someone was actively rude to me when I had fucked up, much less when I was doing a great job, I can guarantee I wouldn’t work any better or faster when it was for them.


  • It isn’t, because their business practices violate the four FOSS essential freedoms:

    1. The freedom to run the program for any purpose
    2. The freedom to study and modify the program
    3. The freedom to redistribute copies of the original or modified program
    4. The freedom to distribute modified versions of the program

    Specifically, freedom 4 is violated, because you are not permitted to distribute a modified version of the program that connects to the Signal servers (even if all your modified version does is to remove Google Play Services or something similar).


  • This particular scenario involves the MacOS desktop app, not the phone app. The link is showing just an image for me - I think it’s supposed to be to https://stackdiary.com/signal-under-fire-for-storing-encryption-keys-in-plaintext/

    That said, let’s compare how it works on the phone to how it could work on MacOS and how it actually works on MacOS. In each scenario, we’ll suppose you installed an app that has hidden malware - we’ll call it X (just as a placeholder name) - and compare how much data that app has access to. Access to session data allows the app to spoof your client and send+receive messages

    On the phone, your data is sandboxed. X cannot access your Signal messages or session data. ✅ Signal may also encrypt the data and store an encryption key in the database, but this wouldn’t improve security except in very specific circumstances (basically it would mean that if exploits were being used to access your data, you’d need more exploits if the key were in the keychain). Downside: On iOS at least, you also don’t have access to this data.

    On MacOS, it could be implemented using sandboxed data. Then, X would not be able to access your Signal messages or spoof your session unless you explicitly allowed it to (it could request access to it and you would be shown a modal). ✅ Downside: the UX to upload attachments is worse.

    It could also be implemented by storing the encryption key in the keychain instead of in plaintext on disk. Then, X would not be able to access your Signal messages and session data. It might be able to request access - I’m not sure. As a user, you can access the keychain but you have to re-authenticate. ✅ Downside: None.

    It’s actually implemented by storing the encryption key in plaintext, collocated with the encrypted database file. X can access your messages and session data. ❌

    Is it foolproof? No, of course not. But it’s an easy step that would probably take an hour of dev time to refactor. They’re even already storing a key, just not one that’s used for this. And this has been a known issue that they’ve refused to fix for several years. Because of their hostile behavior towards forks, the FOSS community also cannot distribute a hardened version that fixes this issue.



  • theoretically they can

    Is this a purely theoretical capability or is there actually evidence they have this capability?

    it’s already been proven that they can tap into anyone’s phone

    Listening into a conversation that you’re intentionally relaying across public infrastructure and gaining access to the phone itself are two very different things.

    The use of proprietary software in literally everything

    1. Speak for yourself. And let’s be real, if you’re on Lemmy you’re 10 times more likely to be running Linux.
    2. Proprietary != closed source
    3. Do you really think that just because something is closed source means that it can’t be analyzed?

    the amount of exploits the NSA has on hand

    How many zero-day exploits does the NSA have? How many can be deployed remotely and without a nontrivial action by a user?

    what’s stopping the NSA from spying this much?

    Scale, capacity, cost, number of employees

    —-

    I’m not saying we shouldn’t oppose government surveillance. We absolutely should. But like another commenter pointed out, I’m much more concerned with the amount of data that corporations collect and have.


  • reasonable expectations and uses for LLMs.

    LLMs are only ever going to be a single component of an AI system. We’ve only had LLMs with their current capabilities for a very short time period, so the research and experimentation to find optimal system patterns, given the capabilities of LLMs, has necessarily been limited.

    I personally believe it’s possible, but we need to get vendors and managers to stop trying to sprinkle “AI” in everything like some goddamn Good Idea Fairy.

    That’s a separate problem. Unless it results in decreased research into improving the systems that leverage LLMs, e.g., by resulting in pervasive negative AI sentiment, it won’t have a negative on the progress of the research. Rather the opposite, in fact, as seeing which uses of AI are successful and which are not (success here being measured by customer acceptance and interest, not by the AI’s efficacy) is information that can help direct and inspire research avenues.

    LLMs are good for providing answers to well defined problems which can be answered with existing documentation.

    Clarification: LLMs are not reliable at this task, but we have patterns for systems that leverage LLMs that are much better at it, thanks to techniques like RAG, supervisor LLMs, etc…

    When the problem is poorly defined and/or the answer isn’t as well documented or has a lot of nuance, they then do a spectacular job of generating bullshit.

    TBH, so would a random person in such a situation (if they produced anything at all).

    As an example: how often have you heard about a company’s marketing departments over-hyping their upcoming product, resulting in unmet consumer expectation, a ton of extra work from the product’s developers and engineers, or both? This is because those marketers don’t really understand the product - either because they don’t have the information, didn’t read it, because they got conflicting information, or because the information they have is written for a different audience - i.e., a developer, not a marketer - and the nuance is lost in translation.

    At the company level, you can structure a system that marketers work within that will result in them providing more correct information. That starts with them being given all of the correct information in the first place. However, even then, the marketer won’t be solving problems like a developer. But if you ask them to write some copy to describe the product, or write up a commercial script where the product is used, or something along those lines, they can do that.

    And yet the marketer role here is still more complex than our existing AI systems, but those systems are already incorporating patterns very similar to those that a marketer uses day-to-day. And AI researchers - academic, corporate, and hobbyists - are looking into more ways that this can be done.

    If we want an AI system to be able to solve problems more reliably, we have to, at minimum:

    • break down the problems into more consumable parts
    • ensure that components are asked to solve problems they’re well-suited for, which means that we won’t be using an LLM - or even necessarily an AI solution at all - for every problem type that the system solves
    • have a feedback loop / review process built into the system

    In terms of what they can accept as input, LLMs have a huge amount of flexibility - much higher than what they appear to be good at and much, much higher than what they’re actually good at. They’re a compelling hammer. System designers need to not just be aware of which problems are nails and which are screws or unpainted wood or something else entirely, but also ensure that the systems can perform that identification on their own.




  • Ah, fair enough. I was just giving people interested in that method a resource to learn more about it.

    The problem is that your method doesn’t consistently generate memorable passwords with anywhere near 77 bits of entropy.

    First, the example you gave ended up being 11 characters long. For a completely random password using alphanumeric characters + punctuation, that’s 66.5 bits of entropy. Your lower bound was 8 characters, which is even worse (48 bits of entropy). And when you consider that the process will result in some letters being much more probable, particularly in certain positions, that results in a more vulnerable process. I’m not sure how much that reduces the entropy, but it would have an impact. And that’s without exploiting the fact that you’re using quoted as part of your process.

    The quote selection part is the real problem. If someone knows your quote and your process, game over, as the number of remaining possibilities at that point is quite low - maybe a thousand? That’s worse than just adding a word with the dice method. So quote selection is key.

    But how many quotes is a user likely to select from? My guess is that most users would be picking from a set of fewer than 7,776 quotes, but your set and my set would be different. Even so, I doubt that the set an attacker would need to discern from is higher than 470 billion quotes (the equivalent of three dice method words), and it’s certainly not 2.8 quintillion quotes (the equivalent of 5 dice method words).

    If your method were used for a one-off, you could use a poorly known quote and maybe have it not be in that 470 billion quote set, but that won’t remain true at scale. It certainly wouldn’t be feasible to have a set of 2.8 quintillion quotes, which means that even a 20 character password has less than 77.5 bits of entropy.

    Realistically, since the user is choosing a memorable quote, we could probably find a lot of them in a very short list - on the order of thousands at best. Even with 1 million quotes to choose from, that’s at best 30 bits of entropy. And again, user choice is a problem, as user choice doesn’t result in fully random selections.

    If you’re randomly selecting from a 60 million quote database, then that’s still only 36 bits of entropy. When the database has 470 billion quotes, that’ll get you to 49 bits of entropy - but good luck ensuring that all 470 billion quotes are memorable.

    There are also things you can do, at an individual level, to make dice method passwords stronger or more suitable to a purpose. You can modify the word lists, for one. You can use the other lists. When it comes to password length restrictions, you can use the EFF short list #2 and truncate words after the third character without losing entropy - meaning your 8 word password only needs to be 32 characters long, or 24 characters, if you omit word separators. You can randomly insert a symbol and a number and/or substitute them, sacrificing memorizability for a bit more entropy (mainly useful when there are short password length limits).

    The dice method also has baked-in flexibility when it comes to the necessary level of entropy. If you need more than 82 bits of entropy, just add more words. If you’re okay with having less entropy, you can generate shorter passwords - 62 bits of entropy is achieved with a 6 short-word password (which can be reduced to 18 characters) and a 4 short-word password - minimum 12 characters - still has 41 bits of entropy.

    With your method, you could choose longer quotes for applications you want to be more secure or shorter quotes for ones where that’s less important, but that reduces entropy overall by reducing the set of quotes you can choose from. What you’d want to do is to have a larger set of quotes for your more critical passwords. But as we already showed, unless you have an impossibly huge quote database, you can’t generate high entropy passwords with this method anyway. You could select multiple unrelated quotes, sure - two quotes selected from a list of 10 billion gives you 76.4 bits of entropy - but that’s the starting point for the much easier to memorize, much easier to generate, dice method password. You’ve also ended up with a password that’s just as long - up to 40 characters - and much harder to type.

    This problem is even worse with the method that the EFF proposes, as it’ll output passphrases with an average of 42 characters, all of them alphabetic.

    Yes, but as pass phrases become more common, sites restricting password length become less common. My point wasn’t that this was a problem but that many site operators felt that it was fine to cap their users’ passwords’ max entropy at lower than 77.5 bits, and few applications require more than that much entropy. (Those applications, for what it’s worth, generally use randomly generated keys rather than relying on user-generated ones.)

    And, as I outlined above, you can use the truncated short words #2 list method to generate short but memorable passwords when limited in this way. My general recommendation in this situation is to use a password manager for those passwords and to generate a high entropy, completely random password for them, rather than trying to memorize them. But if you’re opposed to password managers for some reason, the dice method is still a great option.