Natanael_L

What's your usecase here? Internal or external messaging?

There's no clear segmentation. There's symmetric and asymmetric primitives (and stuff that doesn't fit into these like ZKP), algorithms, protocols, research in many different types of attacks against each of these, research in design and defenses, and plenty of people will cover completely different subsets.

"don't" roll your own cover everything from "don't design your own primitive" to "don't make your own encryption algorithm/mode" to "don't make your own encryption protocol", to "don't reimplement an existing version of any of the above and just use an encryption library"

(and it's mostly "don't deploy your own", if you want to experiment that's fine)

The fact that every email encryption integration exports secure context messages into insecure contexts when decrypting (which is how encrypted messages end up cited in plaintext) means email can't be secured.

This is true both for GPG and S/MIME

Email encryption self-compromises itself in a way Signal doesn't

You need a private PKI, not keyring. They're subtly different - a PKI can handle key rotation, etc.

Yes there aren't a lot of good options for that. If you're using something like a Microsoft software stack with active directory or similar identity/account management then there's usually some PKI support in there to anchor to.

Across organisations, there's really very very few good solutions. GPG specifically is much too insecure when you need to receive messages from untrusted senders. There's basically S/MIME which have comparable security issues, then we have AD federation or Matrix.org with a server per org.

You could say, we do not need gpg, because we control the mailserver, but what if a mailserver is compromised and the mails are still in mailboxes?

How are you handling the keys? This is only true if user's protect their own keypairs with strong passwords / yubikey applet, etc.

What you described IS WHY age is the better option.

GPG's keyring handling has also been a source of exploits. It's much safer to directly specify recipient rather than rely on things like short key IDs which can be bruteforced.

Automatic discovery simply isn't secure if you don't have an associated trust anchor. You need something similar to keybase or another form of PKI to do that. GPG's key servers are dangerous.

You technically can sign with age, but otherwise there's minisign and the SSH spec signing function

Then your next best bet is Matrix.org. Not to the same security standard as Signal, but if you don't have a specific threat against you then it's fine.

Asking for an equivalent to GPG is like asking for an equivalent of a Swiss knife with unshielded chainsaws and laser cutters.

Stop asking for it, for your own good, please. If you don't understand the entire spec you can't use it safely.

You want special purpose tools. Signal for communication, Age for safer file encryption, etc.

What exact problems did you have with age? You're not explaining how it broke anything. Are you compiling yourself? Age has yubikey support and can do all you described.

if your fancy tool has less than 5 years of proven maintenance record, it won't do. Encryption is for the long term. I want to be able to read my stuff in 15-30 years.

This applies to algorithms, it does not apply to cryptographic software in the same way. The state of art changes fast, and while algorithms tend to stand for a long time these days there are significant changes in protocol designs and attack methods.

Downgrade protection, malleability protection, sidechannel protection, disambiguation, context binding, etc...

You want software to be implemented by experts using known best practices with good algorithms and audited by other experts.

C2PA has the problem that it has a ton of optional metadata support and no well-defined strict validation procedure, so it's trivial to make fake photos appear valid using currently available C2PA enabled software.

They absolutely must define a much stricter mode that actually means something, and distinguish it from what they have now (which is essentially prototype level in terms of security model)

Also, the RPi is the wrong kind of hardware for attestation, at least use something like USB Armory which provides a user programmable ARM TrustZone environment.

Since USB Armory supports pinning multiple keys for secure boot (and IIRC protected storage), you could even deliver it set up with a manufacturer attestation key and allow the user to load and pin their own attestation key (useful for an organization like a news company) as well as allowing "dual boot" between the attested firmware signed by the pinned manufacturer key and the user's own firmware. I've wanted that kind of behavior in consumer hardware for a long time, where you have full freedom between using the locked down OEM environment or your own and switching between them freely.

(I assume the USB Armory might also not be ideal in terms of ability to sleep and boot speed, etc, but if you have a quicker smaller controller that's the main board then it could wake the one that supplies attestation and make that functionality available after it's done booting)

... At which point the only new data that chatgpt can reliably scrape is its own answers...

Everything is open source so yes you can, it's mostly a question of practicality.

There's already third party clients, account hosting servers, etc, as well as different apps building on the same system (and which can use the same accounts and data store!) like blogs and more. Most devs are trying to coordinate their custom extensions so it doesn't cause conflict.

If it weren't coordinated we'd easily end up in the same place as Mastodon with their spurious server blocks where large parts of conversations are broken for most users.

Before Musk, Twitter used to fight those requests.

The platform can not be called better, with more bugs and errors than ever.

Why don't they apply those rules to Republicans? Why can they specifically post stuff like private info about Hunter?

Musk is reposting actual neonazi accounts

Most of that doesn't deserve to be called an improvement. That message encryption is one of the worst designs I've ever seen. The algorithm isn't open enough that anybody can see if what it's doing matches the code.

And instead of censoring "secretly" in partnership with the US government they do so in partnership with the Indian government as well as individual Republican politicians.

It's used in a not particularly advanced way - bluesky uses repositories per each user for all their public social activity (posts, likes, etc) and it creates a Merkle tree as an index for them and signs that index (this enables stuff like authenticated content addressing and efficient verification).

SQLite simply stores those posts and that signed Merkle tree. The PDS account host server also has another SQLite DB with a list of its accounts.

They have fancier stuff in their appview server and relay server

It's currently built into the applications, not configurable by default. It's preferable if everybody in a thread / space / community uses the same one because otherwise differences can cause validation failures and conflict and thus break threads, resulting in that people can't follow many discussions, thus applications don't really expose it.

It's the kind of thing where it's preferable that either everybody switch at once, or that new applications with different "lexicon" (post types / social media format) picks a new default from the start.

Signal relies on the client program to not be compromised to keep conversations secret

There's a few self hosting forums, and there's Lemmy / Kbin for federated ones

Since you own the console you dump the keys from, nope

Re forms: I did primarily mean rather simple ones (like say attendance forms), but there's a bigger argument here;

This type of API copyright would post likely not just mean the paper form is under copyright protection, but that the software to OCR scan it and parse it would also likewise be protected - as it is an ordered series of keywords with types, etc. It would then be a license infringement to parse forms without a license.

Independent creation is legal defense, not a cause for dismissal of a suit. You need to prove it - which becomes harder if they can argue you saw their work first and imitated theirs.

There's precedence where people have created their own works from scratch and held to be infringing because they mimicked an existing work too closely (like one case of a photo of a red London bus), and in civil copyright lawsuits the other copyright holder only needs to show its likely, which may reduce to showing you knew their work existed.

The irony is that what they claim happened is instead what would have happened only if the case was resolved in the opposite direction. Everybody having to pay for API licenses for absolutely everything would be disastrous. The gridlock would be insane.

As others has said elsewhere, the jury rules on facts and judges rules on law. SCOTUS are judges. Under one interpretation of law, the most recent jury findings of fact held that Google infringed.

SCOTUS altered the interpretation of the law, thus removing the legal justification for why the jury found infringement. Since they did not alter any findings of fact (they did not need to) this ruling is legally fine.

A jury can say you definitely did X, that court's judge can say X is illegal, and SCOTUS can then declare X is legal so it doesn't matter anymore if you did X.

How often does the API itself exceed the level of creativity of uncopyrightable plain lists of facts? It's not clear to me that it should be considered copyrightable on its own, especially with the fact that copyright explicitly do not cover functional elements. The declarations only instructs you on how to interact with the actual code, and AFAICT rarely add any creative height on top of what's in the main source code.

If presence and order of keywords was sufficient, such legal precedence would create collateral damage at levels that is beyond absurd - outside of software, this would extend to atypical calendar formats, plenty of paper forms, automatic telephone voice menus, map projections, and so much more. Calling it "destructive" wouldn't suffice. Entire industries would be leveled by uncooperative rent seekers that hold old copyrights.

One of the issues here is that it's not even clear under which license the API should be covered. Does the existing software license also cover the API, or must it be explicitly defined?

What happens when an API is co-created by different software developers which each creates their own software under different licenses, through communications which themselves aren't explicitly licensed (like over email lists), and then summarize what they agree on in text instead of code (like the RFC process)?

At no point have either one of them explicitly given permission to use their respective contributions under another license. Even if they agree that the RFC text is public domain, that technically do not extend to implementations of the API which it describes (as those are different works!). And there exists no official reference code with legal approval from all contributors, whose license could be adopted by other developers.

It would be such a mess...

Their failure to take control over those markets is not the same as a failure to cause damage. They slowed down development of web standards by many many years, as one example.

It also saved open source software which reimplements proprietary API:s

Independent copyright when a work was independently created is a thing in most jurisdictions, as copyright covers copying and is not like patents in that regard.

However, that would indeed require a ton more work to prove that you did not copy any of the generated work and truly did create yours by yourself.

Something I've said before: believing that you are a good person is dangerous, because it makes you likely to assume that what you're doing is also good just because you have good intent.

It's better to focus on trying to do good, to keep learning and adjusting.

"who would willingly attack themselves to prevent their own abuse of the power they've newly gained? Only a rare few, I doubt that will change."

Of relevance - the "least privilege principle" in computer security involves designing the system to prevent itself from doing anything which it isn't outright required to do. It involves the host of a service to even lock themselves out of as much potential access as possible (for example via end-to-end encryption).

I also think trust is the single biggest issue here.

The more you trust somebody the more leeway you will give them in how they can express themselves to you, because you expect them to be honest and you assume that they mean well. You are more willing to interpret ambiguity favorably. From experience this seems to be a rather universal phenomenon. I often determine how I should express myself to people based on how much I think they trust me, and this approach seems to work well enough.

Most jurisdictions' copyright law covers translations as derivative work which is still protected.