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

Pretty sure you’re right - there’s the concern of the resources / energy needed for recycling but also, recycling decreases the need for new materials enough to offset that.

That said, AFAIK paper and cardboard are the only thing that can be both composted and recycled, so the advice of the person you replied to is still generally good.

This is the guidance I’ve seen on the topic:

Recycle:

• clean, dry paper
• clean, dry cardboard

But compost:

• soiled and wet paper/cardboard
• pizza boxes and other similar things
• paper towels
• paper/cardboard egg cartons

Don’t compost (throw away if unsuitable to recycle):

• glossy paper
• paper with plastic attached
• anything (e.g., paper towels) with cleaning chemicals or other substances unsuitable for composting on it

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.

They probably have experience with Spring

I understand that

I’m not convinced

the proof is in the pudding with this one

It isn’t.

as you must also ask yourself why E15 is banned during summer months in the first place.

I did. And I shared that in my comment above.

Your source doesn’t share any data on the topic, even just as a summary, but it links to summertime smog, which links to “smog-causing pollutants”, which says:

Section 211(h)(1) of the Clean Air Act prohibits the sale of gasoline that has a Reid Vapor Pressure greater than 9.0 psi during the “high ozone season,” which runs from June 1 to September 15. (RVP is a measure of volatility; high-RVP gasolines release more volatile organic compounds into the troposphere where those VOCs contribute to ozone formation.) Gasoline-ethanol blends below E50 are more volatile than straight gasoline and cannot readily meet the 9.0 psi RVP requirement. Congress created a “one-pound waiver” at Section 211(h)(4) that increases the RVP limit from 9.0 psi to 10.0 psi, but—and here’s the catch—the waiver is only available to “fuel blends containing gasoline and 10 percent denatured anhydrous ethanol.” That is, only E10 can take advantage of the one-pound waiver. Although E15 is slightly less volatile than E10, its RVP still exceeds 9 psi. It needs a one-pound waiver to meet Section 211(h)’s RVP limit in the same way that E10 does, but it is not eligible for one under current law.

The article’s justification for why E15 isn’t legally permitted is that there’s a law against it, which is circular logic. From the environmental protection perspective, it doesn’t sound like there is data suggesting that E15 on its own is worse for the environment than E10. If the only argument is a legal one, it’s not a good argument.

If you can answer that question you’ll likely find the information you’re looking for.

I did, and I shared that answer in my comment above, too - but it’s not the answer you seem to think it is.

Do you disagree that the US isn’t supporting Israel, then, or do you disagree that what Israel is doing to Palestinians amounts to genocide?

Some reading for you in case you’re somehow not familiar with the topic:

• https://jewishcurrents.org/a-textbook-case-of-genocide
• https://en.m.wikipedia.org/wiki/Palestinian_genocide_accusation
• https://www.ohchr.org/en/press-releases/2023/11/gaza-un-experts-call-international-community-prevent-genocide-against
• https://worldwithoutgenocide.org/genocides-and-conflicts/israel-palestine-conflict-history-causes-and-international-law
• https://news.un.org/en/story/2024/03/1147976
• https://www.972mag.com/lavender-ai-israeli-army-gaza/
• https://www.bbc.com/news/world-middle-east-67922346

Even if the international courts don’t rule that Israel is committing genocide, that will necessarily have been influenced by the United States’s close ties to Israel, so that they haven’t yet said whether it is or isn’t genocide is irrelevant. According to the evidence we have, it is.

That said, see also the intro of https://en.m.wikipedia.org/wiki/Native_American_genocide_in_the_United_States

Others, like historian Gary Anderson, contend that genocide does not accurately characterize any aspect of American history, suggesting instead that ethnic cleansing is a more appropriate term.

I’ve seen that same statement by people opposed to the use of the word “genocide” when talking about Israel’s genocide of Palestine, and it’s just as credible there as when “historian Gary Anderson” said it. At best, such a stance is pedantic; at worst, it supports Israel’s genocide by denying and enabling it.

Afaict from reading that (and one of the sources, and its source) it boils down to the fuels’ “RVP levels” (which have an impact on volatility and the amount of VOCs given off) being past a particular threshold. E10 is also past that threshold, but it has an exception that E15 doesn’t have. However, by that same measure, E15 is less volatile than E10.

The author also expressed concern about expanding corn production as a result of expanded E15 and that there haven’t been sufficient studies on the impact of E15 on the environment (particularly in the summer months). But that’s also paired with a statement saying that “consumers don’t want E15,” which detracts from the previous arguments; if true it means their impacts, if any, would be minimal.

I didn’t read every link from that page but none gave a better reason.

My takeaway is that it sounds like we don’t have any data showing that E15 is worse than E10, so the obvious move is to actually start funding those studies.

I also found https://foe.org/blog/2012-05-understanding-e15/ which is very anti-E15; however I wasn’t able to verify their claims because none of the linked articles loaded for me.

If your Java dev is using Jackson to serialize to JSON, they might not be very experienced with Jackson, or they might think that a Java object with a null field would serialize to JSON with that field omitted. And on another project that might have been true, because Jackson can be configured globally to omit null properties. They can also fix this issue with annotations at the class/field level, most likely @JsonInclude(Include.NON\_NULL).

More details: https://www.baeldung.com/jackson-ignore-null-fields

“Glue is not pizza sauce” seems like a common fact to me but Googles llm disagrees for example.

That wasn’t something an LLM came up with, though. That was done by a system that uses an LLM. My guess is the system retrieves a small set of results and then just uses the LLM to phrase a response to the user’s query by referencing the links in question.

It’d be like saying to someone “rephrase the relevant parts of this document to answer the user’s question” but the only relevant part is a joke. There’s not much else you can do there.

Is it possible to force a corruption if a disk clone is attempted?

Anything that corrupts a single file would work. You could certainly change your own disk cloning binaries to include such functionality, but if someone were accessing your data directly via their own OS, that wouldn’t be effective. I don’t know of a way to circumvent that last part other than ensuring that the data isn’t left on disk when you’re done. For example, you could use a ramdisk instead of non-volatile storage. You could delete or intentionally corrupt the volume when you unmount it. You could split the file, storing half on your USB flash drive and keeping the other half on your PC. You could XOR the file with contents of another file (e.g., one on your USB flash drive instead of on your PC) and then XOR it again when you need to access it.

What sort of attack are you trying to protect from here?

If the goal is plausible deniability, then it’s worth noting that VeraCrypt volumes aren’t identifiable as distinct from random data. So if you have a valid reason for having a big block of random data on disk, you could say that’s what the file was. Random files are useful because they are not compressible. For example, you could be using those files to test: network/storage media performance or compression/hash/backup&restore/encrypt&decrypt functions. You could be using them to have a repeatable set of random values to use in a program (like using a seed, but without necessarily being limited to using a PRNG to generate the sequence).

If that’s not sufficient, you should look into hidden volumes. The idea is that you take a regular encrypted volume, whose free space, on disk, looks just like random data, you store your hidden volume within the free space. The hidden volume gets its own password. Then, you can mount the volume using the first password and get visibility into a “decoy” set of files or use the second password to view your “hidden” files. Note that when mounting it to view the decoy files, any write operations will have a chance of corrupting the hidden files. However, you can supply both passwords to mount it in a protected mode, allowing you to change the decoy files and avoid corrupting the hidden ones.

It sounds like you want these files to be encrypted.

Someone already suggested encrypting them with GPG, but maybe you want the files themselves to also be isolated, even while their data is encrypted. In that case, consider an encrypted volume. I assume you’re familiar with LUKS - you can encrypt a partition with a different password and disable auto-mount pretty easily. But if you’d rather use a file-based volume, then check out VeraCrypt - it’s a FOSS-ish [1], cross-platform tool that provides this capability. The official documentation is very Windows-focused - the ArchLinux wiki article is a pretty useful Linux focused alternative.

Normal operation is that you use a file to store the volume, which can be “dynamic” with a max size or can be statically sized (you can also directly encrypt a disk partition, but you could do that with LUKS, too). Then, before you can access the files - read or write - you have to enter the password, supply the encryption key, etc., in order to unlock it.

Someone without the password but with permission to modify the file will be capable of corrupting it (which would prevent you from accessing every protected file), but unless they somehow got access to the password they wouldn’t be able to view or modify the protected files.

The big advantage over LUKS is ease of creating/mounting file-based volumes and portability. If you’re concerned about another user deleting your encrypted volume, then you can easily back it up without decrypting it. You can easily load and access it on other systems, too - there are official, stable apps on Windows and Mac, though you’ll need admin access to run them. On Android and iOS options are a bit more slim - EDS on Android and Disk Decipher on iOS. If you’re copying a volume to a Linux system without VeraCrypt installed, you’ll likely still be able to mount it, as dm-crypt has support for VeraCrypt volumes.

• 1 - It’s based on TrueCrypt, which has some less free restrictions, e.g., c. Phrase "Based on TrueCrypt, freely available at http://www.truecrypt.org/" must be displayed by Your Product (if technically feasible) and contained in its documentation.”

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.

That’s still a single point of failure.

So is TLS or the compromise of a major root certificate authority, and those have no bearing on whether an approach qualifies as using 2FA.

The question is “How vulnerable is your authentication approach to attack?” If an approach is especially vulnerable, like using SMS or push notifications (where you tap to confirm vs receiving a code that you enter in the app) for 2FA, then it should be discouraged. So the question becomes “Is storing your TOTP secrets in your password manager an especially vulnerable approach to authentication?” I don’t believe it is, and further, I don’t believe it’s any more vulnerable than using a separate app on your mobile device (which is the generally recommended alternative).

What happens if someone finds an exploit that bypasses the login process entirely?

Then they get a copy of your encrypted vault. If your vault password is weak, they’ll be able to crack it and get access to everything. This is a great argument for making sure you have a good vault password, but there are a lot of great arguments for that.

Or do you mean that they get access to your logged in vault by compromising your device? That’s the most likely worst case scenario, and in such a scenario:

• all of your logged in accounts can be compromised by stealing your sessions
• even if you use a different app for your 2FA, those TOTP secrets and passkeys can be stolen - they have to be on a different device
• you’re also likely to be subject to a ransomware attack

In other words, your only accounts that are not vulnerable in this situation solely because their TOTP secret is on a different device are the ones you don’t use on that device in the first place. This is mostly relevant if your computer is compromised - if your phone is compromised, then it doesn’t matter that you use a separate password manager and authenticator app.

If you use an account on your computer, since it can be compromised without having the credentials on device, you might as well have the credentials on device. If you’re concerned about the device being compromised and want to protect an account that you don’t use on that device, then you can store the credentials in a different vault that isn’t stored on your device.

Even more common, though? MITM phishing attacks. If your password manager verifies the url, fills the password, and fills your TOTP, then that can help against those. Start using a different device and those protections fall away. If your vault has been compromised and your passwords are known to an attacker, but they don’t have your TOTP secrets, you’re at higher risk of erroneously entering them into a phishing site.

Either approach (same app vs different app) has trade-offs and both approaches are vulnerable to different sorts of attacks. It doesn’t make sense to say that one counts as 2FA but the other doesn’t. They’re differently resilient - that’s it. Consider your individual threat model and one may be a better option than the other.

That said, if you’re concerned about the resiliency of your 2FA approach, then look into using dedicated security keys. U2F / WebAuthn both give better phishing resistance than a browser extension filling a password or TOTP can, and having the private key inaccessible can help mitigate device compromise concerns.

If you only need one factor to log into your password manager, you’re doing it wrong.

Apparently it’s still being actively developed! I’m impressed.

April 15, 2024 Lynx v2.9.1 release

I haven’t worked with Scribus but I’ve heard good things about it, so I don’t think you’d be making a wrong choice by going with it. For this use case, the main reasons I can think of for why LaTeX would be preferable would be:

• if you preferred working with it, or with a particular LaTeX tool
• if you want to learn one tool or the other
• if being able to write a script to create the output is something you want to do and the equivalent is not possible in Scribus