I agree that we need capabilities. But they are not sufficient, because a) capabilities still by definition allow harm within the capability (and think also about how to securely update the capability system) and b) there will be bugs to bypass the capability security as e.g. many processors in the wild will be vulnerable to side-channel attacks like Spectre for quite some time to come.
We also need verified reproducible builds. That alone would have fully defeated SolarWinds. Most open source projects do not need to sign, they shouldn’t not roll their own updater, they just need to provide build scripts that are reproducible. Reproducers are the ones who need to sign to attest the software is built in a specific way from specific inputs (e.g. by running https://github.com/in-toto/rebuilderd ). Software repositories provide an automatic updater (package manager) client that needs to verify that a few chosen reproducers attested. Chosen means by the end user, but sensible default provided by the people managing the repository. Those attestations need to be secured with an observed global append only log / binary transparency log.
Additionally that automatic updater needs to be able to check for signed attestations of additional post merge code reviews (somewhat like https://github.com/crev-dev/cargo-crev ).
We need capabilities to not review things where capabilities do the work sufficiently. But even for these we still need (2) and (3) to be able to undo successful attacks.
But they are not sufficient, because a) capabilities still by definition allow harm within the capability
This is true, but capability systems enforce two important principles:
The principle of least privilege.
The principle of intentional use.
Most of the attention goes to the first of these, because reducing privileges is an obvious win, but I think a lot of the real value comes from the second. In a capability system, it’s not sufficient to be authorised to perform an action, you need to explicitly present the capability associated with that operation to authorise it. This prevents a lot of confused-deputy style attacks. The big Exchange vulnerability a year or so ago, for example, was the result of an intentionality violation: Exchange was able to write files anywhere but shouldn’t have exercised that right in the context of writing the files that unprivileged users could ask it to write. In a capability system, that write would have come with an authorising capability and if someone had passed the write-anywhere-in-the-FS capability to that code path it would have been an obvious bug.
(and think also about how to securely update the capability system)
Why? What problems do you see capabilities introducing in secure updates?
Completely agreed on points 2 and 3. There was work sponsored by the Linux Foundation on package transparency a decade ago (reproducible builds, every build published on a public Merkel Tree so you could easily check your packages were the same ones other people were installing and were the same ones you got from source builds of a particular package) and it seems to have gone nowhere.
Capabilities don’t introduce any problem in updates. They just don’t help in detecting if the new binary is not malicious. (As to construct a capability for that would require knowing what a future update contains before it is made.)
Verify reproducible builds on the pypi servers and pip clients (this includes the source archive built from where people change the source e.g. a git repo) and optionally during packages their CI.
Sign commits and reviews (either in the same repo or after merge with something like https://github.com/crev-dev/cargo-crev ). Put the public keys in the same git repo, so key changes are protected by signatures by the set of allowed keys ( https://gitlab.com/source-security/git-verify proposes a way to do this ). Then verify this at the start of verifying reproducible builds. This is also where insecure use needs to be rejected.
Keep a history of package name transfers ( https://peps.python.org/pep-0541/ ) or removed packages or other compromises with signatures by the people who decide these for that namespace. Protect the history in the same way like package sources. Only allow breaking the chained history of keys in a package by this process or using a different package name.
Secure this by an observed global append only log / binary transparency, make pip clients verify this.
This has the advantages that
the security properties can be offline verified after the fact.
there is a way to detect when the claim that was signed is wrong.
this isn’t vulnerable to third parties.
everything except the namespace is decentralised.
explicit Web of Trust is not required.
keys and their changes are transported inline and thus there is no need for keyservers.
key rotation is supported without needing manual review at consumers.
it allows co-existence in the same source repository of entirely different protocols for signatures than OpenPGP, like ssh signatures.
Conversely one should
not support OpenID Connect, but instead use reproducible builds to verify the content.
not enforce transport 2fa, but instead verify multiple reviews happened.
not trust a central server to never be compromised
My understanding is that in git, signing every commit is an anti-pattern/not useful – which even Linus seems to have said upon a time – and that instead one should (if signing at all) sign tags.
The OpenPGP ecosystem is absolutely not alive and well, if alive and well includes the things that the ecosystem has historically maintained (synchronizing keyservers, a web of trust, etc.). The existence of a memory safe implementation is good, but does very little to address the basic format and cryptographic problems that are baked into OpenPGP’s standards. Fixing those requires standards changes, at which point we’re better off with something without the baggage.
when i say “alive and well” i mean that the core & associated technologies are being actively developed and there is a healthy ecosystem with strong support for existing standards and tools.
SKS has (effectively) been completely deprecated by the community in favor of https://keys.openpgp.org; i don’t use web of trust at all and have no strong opinions on it.
competing technologies like age are convenient but i have little confidence that they’ll ever see the same degree of support that OpenPGP has in software (e.g. git) or hardware (e.g. Yubikey, Nitrokey).
EDIT: i feel like it’d be a little too long-winded to respond to all of those blog posts in a single comment, but just to pick on Matt Green: his criticisms of PGP are a little silly to apply here because he seems to be speaking mostly from the perspective of using it to secure communication (e.g. email and chat).
perfect forward secrecy doesn’t really make sense in the context of OpenPGP when you have other tools for communication that implement cryptographic protocols designed for that purpose.
[Matt Green’s] criticisms of PGP are a little silly to apply here because he seems to be speaking mostly from the perspective of using it to secure communication (e.g. email and chat).
To a layman like me, PGP’s primary use case seems to be secure communication (specifically email). So PGP isn’t a good tool for this use case then?
it depends entirely on what your threat model is; in its current state i wouldn’t recommend PGP for communication to a layperson, but for a savvy individual with specific threat models & use-cases it is still a best-in-class tool.
for the average software developer/maintainer, however, PGP is probably most useful for authentication & signing (i.e. cryptographic identity) + as a primitive that other tools (with better UIs) can use for encryption operations.
for authentication: i loaded up my PGP keys onto several Yubikeys and use them as my SSH credentials. between that & Secure Enclave on my mobile devices, i have almost completely done away with private keys on durable storage.
for signing: one can use PGP to verify git commits (although this can be done with an SSH key now, not all forges support it).
for encryption: PGP sucks to use directly but is fantastic in conjunction with tools like mozilla/sops & pass (or gopass) for sharing development secrets in a project without relying on 3rd-party infrastructure.
The criticisms of PGP are not rooted in its lack of centralized ownership. They’re rooted in what a mess it is, both in terms of the user experience and the actual cryptography.
I get the impression that the political climate (for want of a better term) has changed in the security community. It used to be heavily invested in privacy, decentralization, and open platforms, and PGP ’s design reflects those values.
The new established wisdom is that centralization is good, open platforms are bad, and multinational corporations are seen as the most competent guardians of consumer privacy.
The arguments against PGP (including the author’s) all read as a disagreement about values, in the guise of a discussion about technical competence.
There are ways to use PGP that are kinda reasonably secure, and ways to use PGP that are interoperable.
Unfortunately, the ways that are secure are not interoperable, and the ways that are interoperable are not secure. Plenty of critiques, including the ones already linked, cover this in detail – if you want a more-secure setup in PGP, for example, you have to either do it in an interoperable/compatible way which requires letting other parties strip off the extra-security bits, or do it in a way that doesn’t allow stripping off the extra-security bits but is as a result non-compatible/non-interoperable with likely large numbers of PGP users’ configurations.
TLS once faced similar issues, but an effort was made to fix it, gradually breaking compatibility with the insecure setups, despite millions of users worldwide being on old, outdated operating systems and browsers, without the ability to update, or even the desire to do so.
PGP’s installed user base is orders of magnitude smaller, technically savvy, and/or heavily invested in security.
PGP’s installed user base is orders of magnitude smaller, technically savvy, and/or heavily invested in security.
Unfortunately, I think the developers of PGP implementations and tooling are much more invested in defending the idea that PGP as-is has no security problems that would need to be fixed by ripping out compatibility with ancient crypto algorithms. And even doing that doesn’t really fix all the potential problems with PGP’s design; like a lot of people have said, the preferable well-designed approach is to support one way to do things, and if it gets broken then you increment the protocol version and switch to a different single way of doing things.
I’m not so sure. TLS and Signal have the advantage that they deal with ephemeral data. Software signatures have a far longer lifetime (and in fact, most of the authors’ criticisms are related to the signatures being old). I think it’s very easy to get into a situation where you’re supporting multiple protocol versions at the same time, (as for example PASETO does) effectively ending up in the same place.
The quiet part of Sigstore that’s buried in the docs:
Currently, you can authenticate with Google, GitHub, or Microsoft, which will associate your identity with a short-lived signing key.
Meaning, you cannot participate in this ecosystem as a signer without an account on one of these privacy-invasive, proprietary services. It wouldn’t surprise me if you can’t ever self-host either given that they seem to intend to have a list of OIDC IdP inclusion criteria that new IdPs will have to meet before being manually included.
That list is out of date: BuildKite is also supported as an IdP, and (IIRC) GitLab is either supported or close to being supported.
The goal is to support high-quality IdPs that meet Sigstore’s claim and integrity requirements, which necessarily excludes random one-off IdPs run from someone’s home server. That doesn’t make them inherently privacy-compromising, however: there’s no reason why a community-hosted IdP couldn’t meet these requirements, and several of the IdPs currently supported (GitHub and BuildKite at the minimum) aren’t tied to any human identity in the first place.
Right, OK, I guess this makes sense - if the entire security of the system rests on the certificate issued by the OIDC authentication process, you want to make sure that authentication process is good. It still makes me uncomfortable though, for a lot of reasons.
Also, doesn’t that mean that anyone with legal authority over the signing IdP can compel the issuance of valid signatures on malicious software? My understanding of Sigstore is pretty hazy (the OIDC stuff I’m only aware of because I was in a talk last year about it) so I could simply be misunderstanding, but that seems like a pretty bad threat model, particularly in a world where governments areincreasinglymoving to compel software developers to insert backdoors. My understanding is that Sigstore signatures are publicly auditable using append-only ledgers a la Certificate Transparency, but this is still… unideal. (Maybe that’s unfair of me though because the current status quo of individual developers carrying signing keys is also subject to government compulsion, unless developers are willing to go to jail, and isn’t even publicly discoverable?)
Sigstore is a public signing system: that means that anybody who can obtain an identity can sign for anything that they have the input for. That means that malicious people can make legitimate looking signatures (for some identity they control) for malicious things via legitimate IdPs; the scheme doesn’t attempt to enforce that only “good” people can sign. In this sense, Sigstore is very similar to Web PKI, and in particular very similar to Let’s Encrypt. The notion of trusted parties comes at the index or endpoint layers, via TUF, a TOFU setup, or something else[^1].
Transparency logs are indeed Sigstore’s main source of auditability, and the primary line of defense against CA compromise. I think there are a lot of legitimate reasons to think this is non-ideal – I think it’s non-ideal! But it’s also a pragmatic decision: CT has been shown to work for the Web PKI, and its distributed auditability has nice “knock-on” qualities (e.g. Firefox not needing to do privacy-compromising CT lookups because other large players do so).
Ultimately, I think it’s correct to point out that Sigstore’s adversarial model doesn’t include developers being forced into inserting backdoors into their own software. I think that’s correct to point out, because no codesigning scheme that I’m aware of can address that. What Sigstore does do is eliminate those adversaries’ stealth factor: if an identity is known to be compromised, the community is able to immediately see everything it signed for.
[^1]: If that sounds vague, it’s because it unfortunately is – it’s an area of active development within Sigstore, and in particular it’s something I’m working on.
In this sense, Sigstore is very similar to Web PKI, and in particular very similar to Let’s Encrypt. The notion of trusted parties comes at the index or endpoint layers, via TUF, a TOFU setup, or something else[^1].
Sure, this makes sense to me. It’s also similar to the status quo; given an arbitrary PGP key signing some (possibly tampered-with) software, you don’t know whether that’s the PGP key of the legitimate author of that software or not.
Ultimately, I think it’s correct to point out that Sigstore’s adversarial model doesn’t include developers being forced into inserting backdoors into their own software. I think that’s correct to point out, because no codesigning scheme that I’m aware of can address that. What Sigstore does do is eliminate those adversaries’ stealth factor: if an identity is known to be compromised, the community is able to immediately see everything it signed for.
I’m uncomfortable with Sigstore’s model but I’m having trouble thinking through exactly why, so I apologize for being unclear/making silly points while I essentially think out loud on the internet - this apology goes for this comment and my grandparent comment, lol. :P
But I think actually what I was trying to get at in the grandparent comment is that this is increasing the number of entities that have to be trusted not to be compromised (whether by compulsion or straight up hacking) - you’re adding the IdP but not subtracting the individual developer. However, it is indeed decreasing the amount of trust you have to place in these entities, because of the transparency logs. I’m not sure whether I personally agree with this although I think I’m starting to warm up to it; essentially you’re trading off needing to trust this extra entity for the ability to theoretically catch any entity making bad signatures and serving them to a subset of users, plus the fact that this system is actually usable and PGP isn’t. (Transparency logs aren’t a major advantage unless the attack is targeted because even under PGP, if the malicious signature is visible globally then there’s your answer - the signing key is compromised.)
Thank you for that link. Will there be any alternative for people who do not want to be vulnerable to certain supply chain attacks this doesn’t prevent and do not want to be vulnerable to third parties?
It desperately tries to distance itself from the “crypto”. The very first question on the FAQ is “Is ATP a blockchain?” with the answer “No. ATP is a federated protocol. It’s not a blockchain nor does it use a blockchain.”
At the same time it describes it’s main data structure like this:
Each mutation to the repository produces a new Root node, and every Root node includes the CID of the previous Commit. This produces a linked list which represents the history of changes in a Repository.
I mean, a linked list of signed objects sounds very much like blockchain. I guess, they want to look more like git than bitcoin. so there’s that.
Speaking of commit lists. Doesn’t this mean that content is never truly deleted? The protocol supports post deletion but don’t the posts stay in previous commits? Wouldn’t it make just a little inconvenient to find those posts as opposed to impossible?
I guess, it’s possible to rewrite the whole history (akin to rebase in git) and resign all the commits but it’s unclear how it should be done.
It’s fascinating to see them reinvent SOAP (with WSDL and XSD, no less) reinvented in JSON.
Documentation is far from good. Most of the functionality is not described at all. Lexicons are just interface definitions (in verbose JSON) with no descriptions.
Having consistent data shape is important for interoperability but not the full story. There’s no explanation of what any particular method does or doesn’t. There’s no recommendation for implementers. For example, app.bsky.actor.getSuggestions described as “Get a list of actors suggested for following. Used in discovery UIs.” Who and how decides what’s returned by this method?
It’s a shame they decided not to use existing standards. For example, app.bsky.embed lexicon seems like it intersects a lot with OEmbed.
It seems federation is expected to be on the smaller side. The whole thing requires Crawling Indexers for the most useful social network functionality: content discovery, and user search. They also expect indexers to take care of “large-scale metrics (likes, reposts, followers)” but I personally don’t care much about that. The issue I see is that there doesn’t seem any functionality for index federation. It appears a user can use multiple indexes to distribute their content and discover other content/users but I don’t know how this protocol handles duplication (when a result is present in multiple indices) or missing content (not present in the used indices but still out there).
In order to achieve result similar to Twitter/Facebook there need to be an index with full view of the network (which would be extremely expensive) or we’re faced with ultimately the same issue we see in the fediverse with the lack of global/distributed search.
Blockchains used for currency ignore data that 50% do not agree about to avoid double spending, and need to throw that data away to avoid economic DOS as storage and bandwidth costs money. But that is the in chain perspective, all blockchain also use a network level that is outside, so network level vulnerabilities bypass the in chain guarantees.
For Git the client decides which branch or other ref to use or which one to throw away.
Proof of stake may be used in blockchains, but without a data type that avoids double spending it is not a blockchain.
Proof of stake may use cleverer algorithms that are not vulnerable to collusion of 50% of peers.
This could be used as part of a solution to ensure write and read availability of solutions to cryptographic challenges like revocation certificates / proofs of compromise of secret keys. This is one way to reduce Sybil attacks that more naive append only logs are vulnerable to (see nothing at stake). Such logs are used in Trillian, CertificateTransparency, sigstore, etc.
Protocols can thus be classified by the answer to the question:
Under what amount of peers colluding for which attacks do which failure modes appear?
Seems for server to server federation this is using IPFS (which is using Kademlia). IPFS itself has no write availability guarantees for content, as those are up to an additional protocol layer.
I’ll be honest, I didn’t pay much attention to cryptocurrencies so I easily might be mistaken. I was under impression that the defining feature of blockchain (as a technology) is that it’s an append-only datastructure that makes it easy to know that it wasn’t tempered with. That is, if I have the latest block and I trust it’s legit, that’s enough to verify that none of the previous blocks was tempered with.
For example, I have my latest Bitcoin block and I trust it’s good, I can download the rest of the blocks and verify on my own they all are good. Same with git, I have my HEAD hash, I can pull the rest of the repo and verify that it’s a descendent of the root commit.
In that sense repo structure in AT Protocol is the same thing.
I see you use “hash chain” to define it. TBH, this is the first time I hear the term. I guess, might be useful to have a separate term for the useful bits for people who want to distance themselves from crypocurrencies.
What you’re describing is a hash chain. Fancier versions are called Merkle trees. They’ve been around since the 1980s..
Bitcoin, I believe, created the term “blockchain” for their usage of a global hash chain with a consensus mechanism for resolving forks. The Wikipedia article I linked to discusses the difference.
In order to achieve result similar to Twitter/Facebook there need to be an index with full view of the network (which would be extremely expensive)
I for one don’t want results similar to Twitter/Facebook. Those results have been catastrophic. My takeaway is that having everything you do exposed to the glare of the whole world creates terrible problems. Humans have not evolved the capacity to have social networks larger than about a hundred people.
Depends on use case. I get what you’re saying but let’s consider the case social media was actually good at: letting me find interesting feeds to follow. I don’t consider authors to be within my “social circle” but I appreciate their expertise, insight, writing style, cat pictures they post or whatever. In AT federation I might be missing some feeds if I don’t participate in all indices. Likewise, my content might not reach the widest audience unless it’s in all the indices.
Coincidentally, ActivityPub has a similar issue. There’s no global search. It’s very hard to bootstrap a feed with interesting content.
I’m not sure why everyone’s focused on the “social” part. Very few people chat with their friends on Twitter or Facebook groups as their main mode of communication. I think “microblog” better reflects the best use of public posting in all social media.
I understand why Fb/Twitter would want to focus on the social aspect (“drive engagement”) but it seems users want microblogs more than engagement. At least that’s the impression I get from both AT and ActivityPub. ActivityPub especially since it’s been in use for a while. In fact they actively want to discourage “engagement” the way it’s driven in Twitter, for example.
The vulnerability notifications are junk even working as intended.
GitHub still believes CVSS scores make sense, and therefore it’s a critical vulnerability, 9.8 out of 10, that if you discover there’s an undocumented method called __private_get_type_id__, choose to implement it manually, and implement it incorrectly, and give attacker a way to control it, then you have a bug. They spammed people with notifications over this.
That’s understandable given the incentives. If you give a vulnerability too high a score, some people will patch it unnecessarily and you’ve made some work for other people. If you give it too low a score and an attacker finds an exploit that does more than you said was possible then people who are exploited will complain loudly that you said they didn’t need to.
This is why memory-safety bugs are usually treated as high severity: they allow the attacker to put the program in a state that is outside of the language’s abstract machine. No one wants to enumerate the set of possible states that it could enter (for all possible compilers and compiler flags) and declare that they’re all safe and no one wants to guess and for an attacker to be right.
I have a lot of sympathy with the OpenBSD view that the severity of a vulnerability is a property of the intelligence of the attacker far more than it is a property of the bug.
I think this incentive model applies to traditional, distro-centered security workflow, where there’s OpenSSL-announce mailing list and what not.
But I think recently we observe a raise of qualitatively different workflow, centered around language package managers. Specifically, these days I see “666 critical vulnerabilities” every time I do npm whatever, and then there’s a false dependabot alarm once in a while.
To me it seems that incentives there are fueled by demand for security theater. There’s a vague uncertainty about supply chain attacks, so me must do something about it. Automatically spamming everyone with notifications is quite a lot of something!
In this model, extra noise is exactly the target function we are maximizing.
Yes, but I don’t think the problem in this case was that the memory-unsafety of the bug was more benign than the 9.8/10 CVSS score suggests. The problem is that it happens in a super super niche misuse of that library only, and CVSS has no way to quantify this kind of thing. If this was C or C++ instead of Rust, reporting “if you misuse this hidden, undocumented library API, you can break safety invariants” would probably not even be considered a bug, let alone a 9.8/10 CVE.
Edit: I think what’s missing for me from CVSS is maybe something like an “exposure score” that answers “given somebody uses the affected piece of software, how likely are they to be exposed to this vulnerability?”.
Where “this is exploitable in the default configuration shipped by Debian, Ubuntu and RHEL” or something is a 10/10 and “this is exploitable if you really go out of your way to create a weird configuration, but we don’t know of any instances of anybody doing this in the real world” is a 1/10.
I don’t disagree that the bug was the wrong category, I’m just pointing out that the consequences for giving something too low a rating are significantly worse than giving it too high a rating and, with that set of incentives, the system will eventually tend towards giving everything ‘10/10: maximum severity’ rating.
I got the impression there is some support somewhere to write coccinelle/semgrep style code matches to check if a security advisory needs action by a usage of the buggy software. I.e. then Dependabot would only notify users of a library that actually use the vulnerable part of the library.
I thought I had seen people talk about Github Advisories / Dependabot using such a matcher for some CVEs. Anyone knows if that is implemented or has a pointer to docs or an example? But maybe it was only a rule for https://github.com/returntocorp/semgrep .
Though then there are denial of service bugs like https://github.com/advisories/GHSA-f8vr-r385-rh5r where for some users of the library there is nothing else to deny. Probably not worth it to make that fact computer legible, just to avoid reading up on a few security issues to know you don’t need to act.
There will always be many responses of “the leopard has not, to date, eaten my face” and “risking a face is well worth it to have a leopard”. Sometimes the answer is simply to decide not to play. Signal will, in the fullness of time, sheepishly admit to a slew of security problems, sharing the complete message stream with various governments, and enact new monetization methods.
Is this based on anything or are you just saying you get the wrong “vibe” from Signal? If so, what would you suggest to replace it? Signal has done a better job at bringing secure, encrypted communications to the masses than any other group or app that I’m aware of, and it’s detractors always seem to have arguments like it feels wrong. And then they typically suggest replacing it with options that either don’t even encrypt basic metadata (like Matrix) or are wildly difficult to use and could never possibly gain mass adoption (like Briar).
There are parts in the security design of Signal that are lacking (though it also did innovate better security in quite a few parts). Signal also fails on some basic security practices, e.g. https://github.com/signalapp/Signal-Desktop/ does have commits and releases that are not signed. I offered to help them specifically with that on their bug tracker, but nobody from Signal signalled interest nor was it fixed in the years since then. Other suggestions that would IMHO improve security they declined with incorrect technical reasoning. I think there are a few of these arguments that are scientifically accurate and would not clash with their anti-federation stance. But IMHO the leopards would still eat your face even if anti-federation is the only issue.
https://github.com/simplex-chat/simplex-chat does read like it has massive security design improvements over some parts that Signal is lacking, however I neither reviewed it in detail nor tested it yet. It seems to satisfy your requirements for suggestions, can you confirm?
Maybe. Signal’s already answered subpoenas in US court (see their writeup here) and they would be in an immense, project-ending amount of legal trouble if it turned out that they were technically able to provide more data, but chose not to reply. I don’t want to accuse you of FUD, but I do want to point out your lack of evidence.
Technically OP didn’t say decrypted messages nor past message stream, which leaves the stream of still encrypted future messages (and their metadata). If the signal organisation or individual employees are being compelled by a court or otherwise under duress to modify the servers to share this, then no technical mechanism is in place to prevent this. Such a protection mechanism is practical.
Furthermore getting the cleartext is also possible in a similar way. None of the signal clients are protected against signal being compelled to create an update that exfiltrates the cleartext of old stored or new messages. It could be prevented by the combination of having security reviewers in multiple jurisdictions, using verified reproducible builds, and using an updater fetching from an observed global append only log / binary transparency.
Is this sufficient evidence for you that it is possible?
AFAIK Signal has no willingness to accept help to implement either of these protections nor willingness to implement themselves. I’m interested in contrary evidence.
Can anyone link the 3 patches submitted to lkml mentioned in the paper?
I had trouble finding them from the little information that is in the paper. That the search on lore.kernel.org doesn’t seem to have a full text index makes this harder.
It’s bad enough that our web browsers connect to third parties “on our behalf” without our consent or knowledge, but it’s even worse that those third parties can continue to “keep tabs” on us in some way (without browser tabs!) while we’re not even actively web browsing
How would an open (idle) TCP connection still request updates over HTTP? The only contrived example I can come up would be websockets…
Also not sure if the author ever heard of TCP socket timeouts and how reliably unreliable they are.
It can be used to track you across websites, i.e. it is a short lived super cookie. Which also means that the state separation to protect against super cookies should help.
Even if it does not close the connection, such a protection would need to not reuse the connection for a different website with separated state. Also clearing state (“cookies” in UI speak) for the website for which the connection is left open needs to from then on never use this connection until it is closed at the normal time out. (Closing the connection before the normal timeout sends the information of this user interaction to the server, but I’m not sure if it is worth it to prevent that, so maybe it is fine to just close it early.)
I don’t know if this is all correctly implemented in Firefox, might be worth it to test and report any deviation as bugs.
I still don’t really follow. How would anything with cookies (HTTP, stateless) work via a shared TCP connection. I’m completely missing the point where this is not just a hanging connection (where the website under certain circumstances would assume you’re there for 20min longer than you are) and nothing else.
Also in the super cookie you mentioned wouldn’t the problem be the reuse of the connection and not the “not closing”?
Yes, it is the reuse. To reuse connections is the reason browsers doesn’t close connections immediately in the first place. Also anything where there is a noticeable behaviour difference, like closing the connection early on some user interaction where it would otherwise idle longer until close.
Half closed TCP connection, sometimes called hanging, have a different state than fully open, idling connections that can start to transmit at any time again. Normal http-cookies are per request, multiple requests can share the same connection. With HTTP keep-alive in serial fashion, with HTTP version >2 generally in parallel. Super cookies do not rely on http-cookies, sometimes they only track users by measuring timing differences.
If you never use that web browser again then it makes no difference. But if you reopen it, the process was not terminated (otherwise the connection would have been closed by the kernel), the connection is still idle and then gets reused.
When the connection to a third party gets reused for a request that is for a different first party than the one it was opened for, that can be used for tracking across the web.
The author omits that the SSPL doesn’t work for the stated purpose in the article, MongoDB, or Elastic. (As discussed before: No need to accept for use. Not practical to comply with when accepted.)
The ACSL also doesn’t work for its stated purpose: As a simplification take capitalist as someone setting terms for workers where that someone controls more than 50% of the capital. Lets for example take a manufacturer of clothes who needs software to run the cutting machine for cloth before sewing. They create a company that is fully worker owned, then rent all the machines to that company and provides any other capital they need to operate under the renters conditions. Such a company is clearly operating under terms set by a capitalist, but is able to use the software under this license. The authors of the ACSL seem to recognize this. It seems to be more intended as art than for purpose.
Many licenses that say they want to be better than open source for some purpose, fail at being fit for that purpose, even more than one of the established license would. I don’t think that would be inherent in such a goal. Though some goals are much more complex to create mechanisms for than others, so that is a reason why people who are serious about such goals usually don’t start with a copyright license.
Even with its holes the AGPL might still be better than the ACSL, if your intention is to ward off capitalists, as it has a share alike requirement, which the ACSL lacks. Having a license that plugs the SaaS-wraps-FLOSS loophole of the AGPL seems worthwhile either way.
A license that you can’t comply with isn’t a license. This article entirely ignores that.
The SSPL is not a license that is practical to comply with while running the software as a service. Neither MongoDB nor Elastic themselves are able to comply with their own license. Nor are they working on being able to.
Nobody can currently run a SASS DB offering with only open source. There will be software in your USB-C cable, your network card, your ethernet switch or something like that. You can’t buy a version of every hardware needed, that works only with open source software.
Yes, the reaction from OSI also doesn’t lead to a practical open source license that plugs the SASS-wraps-FOSS loophole. People with power in OSI have been against stronger copyleft.
I do not fully understand the difference between SSPL and AGPL, can someone explain it to me? Is AGPL not considered open source? I think this may be the question to Drew?
If I understand correctly SSPL would force Amazon to open source anything that touches ElasticSearch eg. their entire platform? Is that right? So that would mean that SSPL violates freedom #0.
I’m unsure that the OSI can be treated as honest brokers here. Open Source means what it says, not what OSI say it means, they can try to be a gatekeeper if they want, but noone’s obliged to take them too seriously.
Take this spew of nonsense (for example):
What a company may not do is claim or imply that software under a license that has not been approved by the Open Source Initiative, much less a license that does not meet the Open Source Definition, is open source software. It’s deception, plain and simple, to claim that the software has all the benefits and promises of open source when it does not.
That’s just incorrect, both factually and legally. Saying “license mets the open source definition” or “license is approved by the OSI” would both be deception. Saying “I believe this license is open source” is not.
“I believe X” is mostly not a testable assertion, also it could be true while X is wrong. It is also not that interesting to know what MongoDB and Elastic are believing, it is interesting what they did. Thus: What could happen if one were to use software under the SSPL? Do MongoDB or Elastic use software they license under the SSPL?
Maybe I’m missing something, but I still don’t see any details in that posts, or the links from it, what disqualifies the SSPL (how does it differ from AGPL?)
Under what condition and how can a client detect that another client noticed and proved that the log gave an incorrect answer? When does this other client do the additional work to notice this if not every client does that work?
Some incorrect answer of interest: giving a different answer to some clients (split view), an entry that was there before isn’t there any more (truncate), missing entry (as not every client validates the full log), response with an additional entry not seen in the log when walking it, a write was tried but is not seen on trying to read it.
I must be missing something. This claims that it addresses the type of supply chain attack that bit SolarWinds, and the load bearing defense here appears to be digital signatures. Didn’t the malware that got introduced into the SolarWinds product have a valid digital signature?
Maybe I’ll spot what I’m missing after some more coffee.
This claims that it addresses the type of supply chain attack that bit SolarWinds, and the load bearing defense here appears to be digital signatures. Didn’t the malware that got introduced into the SolarWinds product have a valid digital signature?
It’s probably too subtle for Before Coffee o’clock.
I recommend reading Taylor Hornby’s Triangle of Secure Code Delivery.
With Gossamer, it isn’t just signatures. It’s also a transparency log and third-party verification (thus, attestations).
What this buys you is more than “don’t run unsigned code”. It’s also “don’t run code unless it was reproduced by $trustedThirdParty from the source code” and/or “don’t run code unless it’s been reviewed by $trustedVendors” too.
This adds more mechanisms for mitigating supply chain attacks, as well as unavoidable transparency that prevents stealth operation.
Your first key is sorta TOFU but with transparency (since it’s published in the ledger).
There is nothing approximating WOT or key signing parties. Looking at it through the PGP lens will lead to confusion.
To verify keys in advanced threat models, you need only confirm that peers see the same view of the ledger. You can compare Merkle roots (Trillian) or summary hashes (Chronicle). Or the lazy way: query Gossamer Servers in addition to running the Synchronizer locally.
(These ledgers are centralized-publish, decentralized-verify, so we don’t need to deal with distributed consensus.)
so we don’t need to deal with distributed consensus
Not in the sense that you need to find agreement, but you still need to notice when you don’t agree to be able to check if this disagreement is a compromise.
Is there even a failure that a log without distributed inconsensus detection can detect that non-chained simple signatures won’t provide?
That makes sense. FWIW, I have an easier time considering the merits without thinking about the SolarWinds mess. That combined with my earlier lack of caffeine obfuscated it a bit for me.
I like the transparency log, especially.
Now we need reproducible builds in a widespread way to give this some teeth.
Getting the various tools to cooperate to that end is such a headache.
It feels like a relatively small budget spent on sponsoring an easy/reliable way to do it for C and C++ projects that use cmake and autotools would have an outsized impact.
Combining ZFS and Linux is a GPL violation anyway, so Linus could not include it in Linux without violating the GPL unless Oracle gave explicit permission (or an exemption) for this, as Linus alluded to.
That’s a strong statement. From what I understand, it’s not allowed to distribute Linux together with ZFS, but building ZFS yourself and using it on your own machine is not a GPL violation, right?
Linus could not include it in Linux
I’m with you there. But I don’t think anyone here has asked him to include it. Rather, this seems to be about Linus making changes to the kernel that make it harder to get ZFS to work on Linux.
Distributing a combination is not the only problem when dealing with the copyright of ZFS on Linux: While I don’t like it, one can also be held liable for copyright infringement that others committed, e.g. by inducement of it. That means this is also a question for when one were to contribute to or distribute ZFS on Linux without combining it.
On a more general matter: It is said, though disputed, that Bryan Cantrill ( on here as @bcantrill ) was one of the biggest proponents of the CDDL. If he were to read this I would like to know from him (and anyone contributing under CDDL, if you care about having/giving a license):
Do you suggest anyone to use the CDDL for new software?
Would you like to have existing software under CDDL move to a different license if that was easy?
Is it worth it to make sure new contributions to existing CDDL software are also available under another license that is less intentionally incompatible with other licenses (like 2-BSD, Apache 2.0 or something)?
#3 CDDL is generally not incompatible with any OSS license, except MAYBE the GPL. The FSF thinks it’s incompatible, and Linus clearly has a perspective here, but he isn’t really saying it’s a Legal issue, mostly an Oracle is evil issue (which everyone already knows). See the above wikipedia entry for the details. But either way it’s never been tested in court, so it’s still unknown if it’s actually incompatible. Certainly the spirit of both GPL and CDDL licenses are compatible.
Plus CDDL is an interesting license as it’s file based, i.e. it’s attached to individual files, not to a project as a whole. Which makes it unique in the OSS license tree. So you could only make new files in the repository/project dual-licensed. You can’t really change a CDDL licensed file unless you also happen to own the copyright(s) to the entire file, which in the case of OpenZFS is now quite broad, and not limited to Oracle alone.
Basically there is OpenZFS which everyone uses (across multiple different platforms), except Oracle, which nobody uses (unless forced, for non-technical reasons). Oracle can not import any of the OpenZFS changes back into their tree (legally speaking) because the Oracle version is no longer CDDL licensed.
OpenZFS has a lot of awesome features that Oracle can’t import into their version. The latest new feature Oracle can’t import is data encryption on disk.
That the GPL and CDDL are incompatible is mostly legal opinion at this point. Certainly the Conservancy has an opinion and the FSF has an opinion, which coincides with your statement of “fact”, but it’s never been tested in courts, and plenty of other lawyers have an opposing viewpoint to yours, so much so that Canonical is willing to bet their business on it. More about the various opinions can be found on the CDDL wikipedia page: https://en.wikipedia.org/wiki/Common_Development_and_Distribution_License
I think most people can agree that in spirit, both are compatible, to some degree, but there is a difference in that GPL is a project based license, and the CDDL is a file-based license(which makes it unique).
I don’t think either perspective can be called fact until the various court systems have ruled one way or another, and I don’t really see anyone itching to find out enough to dump a team of lawyers in front of the court.
I’m certainly not going to say you are wrong, and Linus has made it very clear he has no intention of incorporating OpenZFS into the Linux tree anytime soon, but I think even if everyone on the planet agreed legally that it could be incorporated I would like to think he(and many others) would hesitate anyway. The Linux tree is already pretty giant, and OpenZFS’s codebase is no slouch either (it’s in the millions of LoC). Plus, there isn’t really a huge benefit in incorporating OpenZFS into the kernel tree, since OpenZFS is cross-OS (Unix, BSD, macOS, Windows, Linux, etc) and the Linux kernel … isn’t.
However, the change that broke SIMD for ZFS was not a technical one; rather, it was a symbol switching from EXPORT to EXPORT_GPL. From the outside, it seemed a deliberate choice to hamper 3rd party module. And it would be fine even in this case, but it somewhat suprised me.
What exactly does EXPORT_GPL mean? I’m not a kernel dev..
It’s a signal from kernel developers that they expect anything using EXPORT_GPL to also be GPL’d code. it’s a legal stance, and not a technical one.
i.e. if you use EXPORT_GPL, then they expect the GPL license (sometimes called “infection”) to apply to your code as well. If you use just EXPORT, then they don’t expect the GPL license to apply to that code.
Symbols which are EXPORTed are considered free to be used by any (out of tree) kernel module, irrespective of the license of that out-of-tree module. “EXPORT_GPL” symbols are intended only to be used by modules licensed under the GPL.
There is no such permission given in the license of Linux. I remember at least one Linux copyright holder explicitly saying multiple times that they reserve the right to sue for copyright infringement irrespective of how the symbol is marked.
While EXPORT_GPL shows that there is at least one person who reserves the right to sue for copyright infringement when using in a module under an incompatible license, EXPORT doesn’t tell you anything more than the text of the license (GPL 2) in itself. EXPORT is not EXPORT_MIT or something like that.
In my opinion google cloud platform
UI sucks like it takes so long to get service up and running. I remember one time I met a someone who worked at google said the same thing since it’s new in the market and trying there best to make the services better. But on the other hand Amazon Web Services is really smooth and it’s really easy to get started with it.
I haven’t use other cloud services but I’m sure each one has there pros and cons
I set up a small openstack instance this past summer and while it was a royal pain to set up it seemed fairly well thought out. The performance was not amazing but not outside the expected performance of an cloud platform. The user experience is about the same as every other cloud platform after everything is set up. One thing I never got completely sorted was how to set up metrics. There’s probably a service for it, but I couldn’t figure out how to get a dashboard with actual (as opposed to provisioned and unused) cpu and memory stats.
See above. It’s an independent open source meta-project contributed to by many large players, but its popularity is on the wane in favor of containers which are much easier to manage.
Openstack is neither redhat nor canonical. It’s an open source project backed by a number of large vendors, but, to be honest, every single time I talk to anyone who’s implemented it in their day job, they said the same thing: Initial build goes great but the upgrade story is a nightmare, and it’s actually a constellation of separate largely independent projects with varying levels of contribution by developers so the amount of polish varies.
The industry is trending towards container based solutions, and RedHat has a very nice container clustering solution for large scale deployments called Openshift.
No skin in this game since I don’t use any of them, just passing along what I hear from folks who do.
I’d recommend OpenStack based over proprietary clouds, but I’m biased. But if one manages an OpenStack installation badly, the experience can be bad.
This thread mentioned containers (OpenShift is based on Kubernetes, which is for scheduling/orchestrating containers) which some people run on top of VMs (I have seen this with OpenShift on OpenStack Nova which uses KVM but also others). If you need VMs, in the long run I’d recommend the other way around: VMs in Containers. Two interesting projects in that space: KubeVirt is more light weight and runs KVM in Kubernetes. Airship is a way to install and update Kubernetes which also can run among others OpenStack in that Kubernetes.
TL;DR: add an Incorrect flag if that makes more people vote; but that won’t be enough, the scoring algorithm needs to be fixed, needs to be made more lobster like.
Incorrect submissions are also spam. Spam is something unsolicited.
Incorrect submissions are not explicitly solicited. Therefore they are also spam. That doesn’t require that you can identify a thing that is being promoted.
You mentioned reputable sources but did not say how you define reputable and whether that is independently testable. Reputation can not replace testing an argument, but if done correctly it can help coordination to find things that are worth testing. I consider incorrect thus a more useful concept here.
What is the goal of flagging? Some reason may be a negative score to filter <0 and/or some admin reaction. Anything else?
Many incorrect submissions still keep a positive score, even after that is shown in the comments. A more specific flag than spam will not necessarily make them go negative. That is not a reason to not add an alias or more specific flag if that makes more humans vote at all on a story.
It happens that incorrect information is scored high on this site. One might want to use a better reputation algorithm to make it easier to find scientifically correct submissions and not waste time with things that are incorrect. One that improves quality over time without resorting to authority or majority-rule. It needs to work on something more specific than one score/tally, like if a tag applies (or even a more expressive assertion). It would require calculating the reputation individually for a user based on who they trust to use a tag correctly. Which is a more lobster like approach, as they don’t form a shared hierarchy but each their own view of it. The trust calculation needs to be able to differentiate between trust for different tags. This trust between two humans needs to be calculated based on tags/assertions they put in this system, not directly. It needs to be able to keep by user choice some input private. It needs to take into account if people acknowledge their errors. (To answer if I make an adversarial collaboration with this person.) It needs a way to avoid Sybil attacks. Explicitly tagging things as “correct scientific argument” is needed to make the goal more obvious and to not exclude fiction, jokes, and allow any categorisation goal. It should be able to tag only a part of a submission.
A good collaborative categorisation system makes it possible to take into account when people agree on a specific assertion without requiring agreement on other or a more general assertions. (The current one fails this by requiring agreement on a the very unspecific “up or downvote”.)
Your above assertion is not specific enough to test or falsify.
Karl Marx didn’t know about falsification (thus science) yet as that was only described after his death. You could write arguments that others can check instead of merely taking your word for it.
In the article you say:
users and corporations do not have aligned incentives […] therefore, so long as capital has the ability & incentive to influence software production, software will be pitted against users.
This is circular reasoning or perhaps a tautology. You give the conclusion as a reason for the conclusion.
Quirky, personal software that is aggressively unscalable
Software for humans (as opposed to only for some humans but not others) is required to be more scaleable than merely commercial software as there are more than 7G of them. Commercial software merely needs to work with enough humans to extract money, it can ignore the rest.
What is more important to you: Human needs/rights or the inability of the software to be used by corporations?
Is a communist revolution your goal in itself or is that only your suggested solution? Are there some goals you have where if some other idea could reach them, it would be fine for you not to get a communist revolution?
Karl Marx didn’t know about falsification (thus science) yet as that was only described after his death. You could write arguments that others can check instead of merely taking your word for it.
I didn’t mention Marx in this essay. However – your statement is incorrect. Marx wrote during the industrial revolution, & his explicitly stated goal was to remove the woo from existing socialist movements (like the fabians) by sticking to rigorously scientific analyses of historical economic data & construct falsifiable models of economics. This is what is meant by the term ‘historical materialism’: an attempt to bring economics out of the realm of Smith’s just-so stories & into the realm of science, submitting it to the same rigors that were then being applied to thermodynamics.
(Last I checked, the scientific method was attributed to Sir Francis Bacon, a few centuries before Marx was born. The nineteenth century was the absolute peak of the kind of scientific reasoning you describe – named and documented by Popper a half century after its moment ended in the wake of the virtual demolition of the analytic movement in philosophy by Godel & Wittgenstein.)
This is circular reasoning
No, I just thought that the incentive misalignment was so obvious that I didn’t need to specify it.
Software for humans […] is required to be more scaleable
This point is fair, so long as you assume the existing division between developer and non-developer. I’ve written at length elsewhere that this division is arbitrary, problematic, and a form of rentseeking, & ought to be abolished. Since you haven’t read those pieces, I can’t blame you for thinking that this is a flaw in reasoning.
What is more important to you: Human needs/rights or the inability of the software to be used by corporations?
Human needs. (After all, like the rest of us, I write software for corporations all day. I maintain that it is problematic in the long run, but in the short run it is necessary for my own survival.)
Is a communist revolution your goal in itself
I’m not really an advocate of revolution per-se. It’s messy & often ineffective, since military structure, while necessary for war, runs counter to an equitable arrangement of people. Gradualism has other problems, but luckily there are solutions that are neither revolutionary nor gradual. My own preference is the scheme outlined in bolo’bolo: the construction of alternatives, independent of existing systems, which people can move to freely. Popular alternatives starve incumbents of labor & resources. In the late stages this is almost guaranteed to result in direct attacks, but by that point, if things are managed well, the incumbents will be too weak to do much damage.
Let me repeat my first sentence with a different focus:
You didn’t refer to a specific model of economics.
You can’t have one without the other.
If you specified a correct economic model and matching implementation, that isn’t yet sufficient for that to follow. For your claim, you’ll need to specify properties without which Free Software can not occur. With enough precision so that it is easy to say if something matches those properties or not.
Marx […] construct falsifiable models of economics.
One can state something falsifiable without explicitly having defined falsifiability or deciding on using it for demarcation to non-science. I only mentioned Marx to be a bit more specific than mentioning the word communism. Marx certainly did make non-falsifiable claims in addition to falsifiable ones.
AFAIK Sir Karl Popper defined falsifiability long after Marx was dead and suggested anything not falsifiable is not science. Francis Bacon didn’t require falsifiability.
No, I just thought that the incentive misalignment was so obvious that I didn’t need to specify it.
There are certainly obvious cases of incentive misalignment. What is not obvious is that in all past, current and possible future systems in our reality, “users and corporations do not have aligned incentives”. (For it to be falsifiable you need to specify how to detect a corporation. Does Alice and Bobs collusion constitute a corporation?)
Software for humans […] is required to be more scaleable
This point is fair, so long as you assume the existing division between developer and non-developer.
[…] this division is […] a form of rentseeking […]
Doesn’t matter under what economic system or how the labour on that software is organised. That does not change that a human would need to be able to run compatible protocols together with over 7G humans for them to be able to not exclude some of them. Otherwise: Sorry, no internet1 for you, its full. Make your own internet2, which won’t fit everyone either. So some won’t be able to directly talk to some others. This would create the opportunity for those in both internets to seek rent for forwarding. Therefore the non-scalable property enabled what you said to avoid.
Unscalable software would compromise the rights of some humans. Thus it does not serve your stated goals.
If you specified a correct economic model and matching implementation, that isn’t yet sufficient for that to follow. For your claim, you’ll need to specify properties without which Free Software can not occur. With enough precision so that it is easy to say if something matches those properties or not.
You’re applying a lot more rigor to a flippant response (to someone’s flippant comment) than to the article itself, wherein I specify exactly what I mean by free software and exactly how it’s currently being prevented & a few ways to close the loopholes that are being exploited.
The goal of free software is to align the incentives of software developers and software users by making them the same group. (If we want to bring Marx into this at all, we have a convenient place to do it: he defines communism as any state of affairs in which the incentives of management and labor are aligned because management and labor are the same group. I wasn’t drawing on Marx in this essay but on Debord, so outside of this point that’s a much more suitable comparison to make.)
The labor of software use always falls upon individuals, so user incentives are best defined by individual incentives. Because almost all individual software users sell their bodies to corporations for at least eight hours a day, during which they are required to perform actions in the ways demanded by corporations rather than in the ways they would naturally perform those actions, points of friction become biased based on standard procedures. It is only in the interests of a corporation to lubricate the points of friction that occur when performing corporate-controlled work, and then only when the people who encounter those points of friction are insufficiently disposable.
Marx certainly did make non-falsifiable claims in addition to falsifiable ones.
Sure, as does everybody. And, Marx was wrong on a number of points (among them, he thought that ‘capitalism with a human face’ was impossible & so thought that the internal contradictions of capitalism would cause it to collapse substantially faster).
He had, as an explicit goal, to be scientific – by which he meant creating systematic models of the entire relevant portion of the problem & testing them against both historical data & new experiments, eschewing metaphysical ideas and wishful thinking in favor of mathematics & mechanisms, and emphasizing the importance of revising models when they have failed to be predictive even when the resulting new model is complicated by this collision between theory and practice. In other words, in terms of Popper’s idea of science (which itself is fairly controversial), Marx’s economics scores higher than many current fields (including practically all of medicine outside of drug testing).
There are certainly obvious cases of incentive misalignment. What is not obvious is that in all past, current and possible future systems in our reality, “users and corporations do not have aligned incentives”.
If we privilege the needs of individuals over the needs of corporations, then any time the two come into conflict and the corporation wins, it is an unnecessary tragedy. When their needs are aligned, it is irrelevant: the equivalent number of individuals coming together in a different structure would have the same power to fulfill that need. When they are not aligned, corporations tend to win, because that is what corporations are for.
you need to specify how to detect a corporation
The usual way will suffice. A corporation is a legal entity that can hold capital and resources the way a person does, and can usually be sued in the way a person can be, in such a way that it forms a buffer between an individual and liability. A corporation continues to exist so long as it periodically pays the government a registration fee, unless it is dissolved by its owners.
This means a corporation always has an incentive to accumulate capital, because accumulated capital is capable of protecting it from all possible risks, & any mechanism for accumulating capital that does not risk losing more capital than the company can afford makes sense (i.e., fines for illegal activity are part of the cost of business & bad PR can be offset by marketing). It also means that the owners of a corporation are incentivized to dissolve a corporation & run off with its capital if they think it’s no longer doing its job. A corporation is a disposable shield that is immortal so long as you keep feeding it, but gets hungrier as it gets bigger: an ideal tool for protecting individuals from the voracious maw of the market.
a human would need to be able to run compatible protocols together
I’m not opposed to the concept of protocols. I’ve got a problem with monocultures.
Software scalability matters a lot with regard to centralization. If one organization owns all the machines for doing a thing, then those machines need to be efficient, because the margins are the difference between skimming enough profit to survive and slowly bleeding to death. In a decentralized system, most of the things we mean by scalability don’t matter: one person isn’t doing maintenance for a thousand machines but for one machine, so it makes more sense for that one person to be comfortable with their one machine than it does for all thousand machines to be interchangable; one person isn’t moderating the feeds of all of malaysia, but instead, everybody tends their own moderation and perhaps helps out with the moderation of their friends.
I’m ultimately less interested in opening up low-level protocols than front ends, because the shape of behavior is controlled by the adjacent possible. I go into this in detail in other essays, but where it intersects with this topic is: when you make software for employees, the people who use it are biased toward acting and thinking like employees, which is a very narrow slice of all the different hats one could wear; likewise, when everybody runs the same software, they think more alike, because their imagination is shaped by their habits.
We know from observing users that they are capable of using an extremely flawed folk-understanding in conjunction with trial and error to produce effective, if convoluted, mechanisms for getting things done with inadequate tooling & inadequate documentation. In other words: all humans are born hackers, and the difference between somebody who rigs up some incredible hairball of an excel spreadsheet to do something & somebody who does it in perl is not a matter of inherent ability or even really skill but of access to the ability to imagine better tooling (i.e., a matter of exposure, education, & identity). Just as MySpace’s willingness to host arbitrary CSS led to often-messy but incredibly personal and expressive profile pages, making the resources available and visible by default to everyone to modify all the code on their system will result in even self-professed ‘non-technical’ users adapting their systems to fit their preferences in extreme ways – and the more available we make that ability to imagine a better fit, the greater variety & the closer fit we will see. (In other words, this is a natural extension of free software: rather than collapsing the distinction between ‘a developer’ and ‘the developer’, truly collapse the distinction between ‘developer’ and ‘user’.)
Even opening up the whole system, we should expect to provide reasonable defaults, because writing an IP stack is an acquired taste – I don’t expect many people to dig that deep when optimizing for a real-world task. Even so, monocultures of implementation are dangerous in many ways, so we ought to have more fully independent reimplementations of just about every protocol. If a protocol cannot be trivially reimplemented, then it has failed at being a protocol. Vary every behavior not specified with ‘must’, bring out the nasal demons, etc: the ecosystem will improve because of it.
Computer software is made for and by people who already like computers, and this prevents problems that are obvious to other groups from being solved. Require less initial buy-in at the level of software creation and you’ll get computers that are worth liking.
some won’t be able to directly talk to some others
If centralized social media has taught us anything, it ought to be that people don’t really want to open themselves up to being talked at directly by seven billion strangers, because scale of direct contact amplifies the power of griefers and low-effort shitposting a lot more than it amplifies useful forms of communication.
SSB has the best model I’ve seen in action. You’re responsible for managing your own feed, but visibility is based on the existing social graph & is asymmetric. Basically, so long as you don’t follow pubs, you can keep the presence of hostile randos looking to bother you down to a dull roar without putting the labor of that on some overworked moderator. Visibility & access follows the usual course of human connectedness, & tactics created by a fully flat network like sealioning and swarming don’t really work.
The author gives no alternative to the web of trust or their arguments against it do not hold up during scrutiny.
Long term identities could be built on rotating keys. Yes, this is one of the many areas where PGP lacks (with its identity key rotation not being user friendly). This is also where Signal lacks (binding long term identity to the phone number only instead of allowing chaining of keys).
None of this identity goop works. Not the key signing web of trust […]
Yet they give no details in which way it doesn’t work. For finding the key of someone you haven’t met, the web of trust idea improves security over trust on first use. Man in the middle attacks work for trust on first use, but don’t on web of trust.
Experts don’t trust keys they haven’t exchanged personally. Everyone else relies on centralized authorities to distribute keys.
They just mentioned web of trust in the same paragraph… What do they think of people who do use the web of trust?
Yes the usability and privacy of web of trust can be improved. See e.g. https://claimchain.github.io/ . Getting introduced to other people is something many people do in real life and did before the Internet existed.
At this time, it’s up to the proponents of web-of-trust to prove that it’s a workable concept, and not a theoretical construct that doesn’t work in today’s world.
The recent brouhaha over keyservers shows that the infrastructure at least is sorely lacking.
At this time, it’s up to the proponents of web-of-trust to prove that it’s a workable concept, and not a theoretical construct that doesn’t work in today’s world.
I personally believe it is a better option than centralized services (remember StartSSL ?) if you use TLS client certificates – see weird CAcert – or OpenSSH keys – see Monkeysphere.
At this time, it’s up to the proponents of web-of-trust to prove that it’s a workable concept, and not a theoretical construct that doesn’t work in today’s world.
Some open-source projects use Web of Trust, for example Arch Linux or kernel.org. IIRC Debian also requires their developers to have “strongly connected” keys.
I agree that we need capabilities. But they are not sufficient, because a) capabilities still by definition allow harm within the capability (and think also about how to securely update the capability system) and b) there will be bugs to bypass the capability security as e.g. many processors in the wild will be vulnerable to side-channel attacks like Spectre for quite some time to come.
We also need verified reproducible builds. That alone would have fully defeated SolarWinds. Most open source projects do not need to sign, they shouldn’t not roll their own updater, they just need to provide build scripts that are reproducible. Reproducers are the ones who need to sign to attest the software is built in a specific way from specific inputs (e.g. by running https://github.com/in-toto/rebuilderd ). Software repositories provide an automatic updater (package manager) client that needs to verify that a few chosen reproducers attested. Chosen means by the end user, but sensible default provided by the people managing the repository. Those attestations need to be secured with an observed global append only log / binary transparency log.
Additionally that automatic updater needs to be able to check for signed attestations of additional post merge code reviews (somewhat like https://github.com/crev-dev/cargo-crev ).
We need capabilities to not review things where capabilities do the work sufficiently. But even for these we still need (2) and (3) to be able to undo successful attacks.
This is true, but capability systems enforce two important principles:
Most of the attention goes to the first of these, because reducing privileges is an obvious win, but I think a lot of the real value comes from the second. In a capability system, it’s not sufficient to be authorised to perform an action, you need to explicitly present the capability associated with that operation to authorise it. This prevents a lot of confused-deputy style attacks. The big Exchange vulnerability a year or so ago, for example, was the result of an intentionality violation: Exchange was able to write files anywhere but shouldn’t have exercised that right in the context of writing the files that unprivileged users could ask it to write. In a capability system, that write would have come with an authorising capability and if someone had passed the write-anywhere-in-the-FS capability to that code path it would have been an obvious bug.
Why? What problems do you see capabilities introducing in secure updates?
Completely agreed on points 2 and 3. There was work sponsored by the Linux Foundation on package transparency a decade ago (reproducible builds, every build published on a public Merkel Tree so you could easily check your packages were the same ones other people were installing and were the same ones you got from source builds of a particular package) and it seems to have gone nowhere.
Capabilities don’t introduce any problem in updates. They just don’t help in detecting if the new binary is not malicious. (As to construct a capability for that would require knowing what a future update contains before it is made.)
Thank you for this analysis. To fix it:
This has the advantages that
Conversely one should
My understanding is that in
git, signing every commit is an anti-pattern/not useful – which even Linus seems to have said upon a time – and that instead one should (if signing at all) sign tags.i feel like this is needlessly inflammatory.
it’s absolutely true that tools like GnuPG have insecure defaults and painful UX, but OpenPGP-the-ecosystem is alive and well.
IMO this is mostly thanks to the Sequoia PGP folks, but that work has been bearing fruit for years at this point.
It’s inflammatory, but it’s also not remotely controversial in cryptographic circles:
The OpenPGP ecosystem is absolutely not alive and well, if alive and well includes the things that the ecosystem has historically maintained (synchronizing keyservers, a web of trust, etc.). The existence of a memory safe implementation is good, but does very little to address the basic format and cryptographic problems that are baked into OpenPGP’s standards. Fixing those requires standards changes, at which point we’re better off with something without the baggage.
when i say “alive and well” i mean that the core & associated technologies are being actively developed and there is a healthy ecosystem with strong support for existing standards and tools.
SKS has (effectively) been completely deprecated by the community in favor of https://keys.openpgp.org; i don’t use web of trust at all and have no strong opinions on it.
competing technologies like
ageare convenient but i have little confidence that they’ll ever see the same degree of support that OpenPGP has in software (e.g.git) or hardware (e.g. Yubikey, Nitrokey).EDIT: i feel like it’d be a little too long-winded to respond to all of those blog posts in a single comment, but just to pick on Matt Green: his criticisms of PGP are a little silly to apply here because he seems to be speaking mostly from the perspective of using it to secure communication (e.g. email and chat).
perfect forward secrecy doesn’t really make sense in the context of OpenPGP when you have other tools for communication that implement cryptographic protocols designed for that purpose.
To a layman like me, PGP’s primary use case seems to be secure communication (specifically email). So PGP isn’t a good tool for this use case then?
it depends entirely on what your threat model is; in its current state i wouldn’t recommend PGP for communication to a layperson, but for a savvy individual with specific threat models & use-cases it is still a best-in-class tool.
for the average software developer/maintainer, however, PGP is probably most useful for authentication & signing (i.e. cryptographic identity) + as a primitive that other tools (with better UIs) can use for encryption operations.
for authentication: i loaded up my PGP keys onto several Yubikeys and use them as my SSH credentials. between that & Secure Enclave on my mobile devices, i have almost completely done away with private keys on durable storage.
for signing: one can use PGP to verify
gitcommits (although this can be done with an SSH key now, not all forges support it).for encryption: PGP sucks to use directly but is fantastic in conjunction with tools like mozilla/sops &
pass(orgopass) for sharing development secrets in a project without relying on 3rd-party infrastructure.Git needs signatures, which AFAIK age doesn’t do (you probably want minisign?). Git supports SSH signatures already tho.
The controversial part is that all of these people you linked imply that we should be vulnerable to a few centralized third parties.
The criticisms of PGP are not rooted in its lack of centralized ownership. They’re rooted in what a mess it is, both in terms of the user experience and the actual cryptography.
I get the impression that the political climate (for want of a better term) has changed in the security community. It used to be heavily invested in privacy, decentralization, and open platforms, and PGP ’s design reflects those values.
The new established wisdom is that centralization is good, open platforms are bad, and multinational corporations are seen as the most competent guardians of consumer privacy.
The arguments against PGP (including the author’s) all read as a disagreement about values, in the guise of a discussion about technical competence.
I disagree. I think what has changed is that usability is now seen as a core part of security. Like the author said:
There are ways to use PGP that are kinda reasonably secure, and ways to use PGP that are interoperable.
Unfortunately, the ways that are secure are not interoperable, and the ways that are interoperable are not secure. Plenty of critiques, including the ones already linked, cover this in detail – if you want a more-secure setup in PGP, for example, you have to either do it in an interoperable/compatible way which requires letting other parties strip off the extra-security bits, or do it in a way that doesn’t allow stripping off the extra-security bits but is as a result non-compatible/non-interoperable with likely large numbers of PGP users’ configurations.
TLS once faced similar issues, but an effort was made to fix it, gradually breaking compatibility with the insecure setups, despite millions of users worldwide being on old, outdated operating systems and browsers, without the ability to update, or even the desire to do so.
PGP’s installed user base is orders of magnitude smaller, technically savvy, and/or heavily invested in security.
Unfortunately, I think the developers of PGP implementations and tooling are much more invested in defending the idea that PGP as-is has no security problems that would need to be fixed by ripping out compatibility with ancient crypto algorithms. And even doing that doesn’t really fix all the potential problems with PGP’s design; like a lot of people have said, the preferable well-designed approach is to support one way to do things, and if it gets broken then you increment the protocol version and switch to a different single way of doing things.
I’m not so sure. TLS and Signal have the advantage that they deal with ephemeral data. Software signatures have a far longer lifetime (and in fact, most of the authors’ criticisms are related to the signatures being old). I think it’s very easy to get into a situation where you’re supporting multiple protocol versions at the same time, (as for example PASETO does) effectively ending up in the same place.
Is there already an alternative in the works? I don’t know much about this space. I hear about this a lot: https://www.sigstore.dev/
The quiet part of Sigstore that’s buried in the docs:
Meaning, you cannot participate in this ecosystem as a signer without an account on one of these privacy-invasive, proprietary services. It wouldn’t surprise me if you can’t ever self-host either given that they seem to intend to have a list of OIDC IdP inclusion criteria that new IdPs will have to meet before being manually included.
That list is out of date: BuildKite is also supported as an IdP, and (IIRC) GitLab is either supported or close to being supported.
The goal is to support high-quality IdPs that meet Sigstore’s claim and integrity requirements, which necessarily excludes random one-off IdPs run from someone’s home server. That doesn’t make them inherently privacy-compromising, however: there’s no reason why a community-hosted IdP couldn’t meet these requirements, and several of the IdPs currently supported (GitHub and BuildKite at the minimum) aren’t tied to any human identity in the first place.
Right, OK, I guess this makes sense - if the entire security of the system rests on the certificate issued by the OIDC authentication process, you want to make sure that authentication process is good. It still makes me uncomfortable though, for a lot of reasons.
Also, doesn’t that mean that anyone with legal authority over the signing IdP can compel the issuance of valid signatures on malicious software? My understanding of Sigstore is pretty hazy (the OIDC stuff I’m only aware of because I was in a talk last year about it) so I could simply be misunderstanding, but that seems like a pretty bad threat model, particularly in a world where governments are increasingly moving to compel software developers to insert backdoors. My understanding is that Sigstore signatures are publicly auditable using append-only ledgers a la Certificate Transparency, but this is still… unideal. (Maybe that’s unfair of me though because the current status quo of individual developers carrying signing keys is also subject to government compulsion, unless developers are willing to go to jail, and isn’t even publicly discoverable?)
Two points:
Sigstore is a public signing system: that means that anybody who can obtain an identity can sign for anything that they have the input for. That means that malicious people can make legitimate looking signatures (for some identity they control) for malicious things via legitimate IdPs; the scheme doesn’t attempt to enforce that only “good” people can sign. In this sense, Sigstore is very similar to Web PKI, and in particular very similar to Let’s Encrypt. The notion of trusted parties comes at the index or endpoint layers, via TUF, a TOFU setup, or something else[^1].
Transparency logs are indeed Sigstore’s main source of auditability, and the primary line of defense against CA compromise. I think there are a lot of legitimate reasons to think this is non-ideal – I think it’s non-ideal! But it’s also a pragmatic decision: CT has been shown to work for the Web PKI, and its distributed auditability has nice “knock-on” qualities (e.g. Firefox not needing to do privacy-compromising CT lookups because other large players do so).
Ultimately, I think it’s correct to point out that Sigstore’s adversarial model doesn’t include developers being forced into inserting backdoors into their own software. I think that’s correct to point out, because no codesigning scheme that I’m aware of can address that. What Sigstore does do is eliminate those adversaries’ stealth factor: if an identity is known to be compromised, the community is able to immediately see everything it signed for.
[^1]: If that sounds vague, it’s because it unfortunately is – it’s an area of active development within Sigstore, and in particular it’s something I’m working on.
Sure, this makes sense to me. It’s also similar to the status quo; given an arbitrary PGP key signing some (possibly tampered-with) software, you don’t know whether that’s the PGP key of the legitimate author of that software or not.
I’m uncomfortable with Sigstore’s model but I’m having trouble thinking through exactly why, so I apologize for being unclear/making silly points while I essentially think out loud on the internet - this apology goes for this comment and my grandparent comment, lol. :P
But I think actually what I was trying to get at in the grandparent comment is that this is increasing the number of entities that have to be trusted not to be compromised (whether by compulsion or straight up hacking) - you’re adding the IdP but not subtracting the individual developer. However, it is indeed decreasing the amount of trust you have to place in these entities, because of the transparency logs. I’m not sure whether I personally agree with this although I think I’m starting to warm up to it; essentially you’re trading off needing to trust this extra entity for the ability to theoretically catch any entity making bad signatures and serving them to a subset of users, plus the fact that this system is actually usable and PGP isn’t. (Transparency logs aren’t a major advantage unless the attack is targeted because even under PGP, if the malicious signature is visible globally then there’s your answer - the signing key is compromised.)
Sigstore is the biggest one that I’m aware of. I’ve been involved with its Python client development1, with use by PyPI being the eventual goal.
Thank you for that link. Will there be any alternative for people who do not want to be vulnerable to certain supply chain attacks this doesn’t prevent and do not want to be vulnerable to third parties?
This is fascinating. A few first impressions.
It desperately tries to distance itself from the “crypto”. The very first question on the FAQ is “Is ATP a blockchain?” with the answer “No. ATP is a federated protocol. It’s not a blockchain nor does it use a blockchain.”
At the same time it describes it’s main data structure like this:
I mean, a linked list of signed objects sounds very much like blockchain. I guess, they want to look more like git than bitcoin. so there’s that.
Speaking of commit lists. Doesn’t this mean that content is never truly deleted? The protocol supports post deletion but don’t the posts stay in previous commits? Wouldn’t it make just a little inconvenient to find those posts as opposed to impossible?
I guess, it’s possible to rewrite the whole history (akin to rebase in git) and resign all the commits but it’s unclear how it should be done.
It’s fascinating to see them reinvent SOAP (with WSDL and XSD, no less) reinvented in JSON.
Documentation is far from good. Most of the functionality is not described at all. Lexicons are just interface definitions (in verbose JSON) with no descriptions.
Having consistent data shape is important for interoperability but not the full story. There’s no explanation of what any particular method does or doesn’t. There’s no recommendation for implementers. For example,
app.bsky.actor.getSuggestionsdescribed as “Get a list of actors suggested for following. Used in discovery UIs.” Who and how decides what’s returned by this method?It’s a shame they decided not to use existing standards. For example,
app.bsky.embedlexicon seems like it intersects a lot with OEmbed.It seems federation is expected to be on the smaller side. The whole thing requires Crawling Indexers for the most useful social network functionality: content discovery, and user search. They also expect indexers to take care of “large-scale metrics (likes, reposts, followers)” but I personally don’t care much about that. The issue I see is that there doesn’t seem any functionality for index federation. It appears a user can use multiple indexes to distribute their content and discover other content/users but I don’t know how this protocol handles duplication (when a result is present in multiple indices) or missing content (not present in the used indices but still out there).
In order to achieve result similar to Twitter/Facebook there need to be an index with full view of the network (which would be extremely expensive) or we’re faced with ultimately the same issue we see in the fediverse with the lack of global/distributed search.
Git uses hash chains.
Blockchains use hash chains.
Blockchains used for currency ignore data that 50% do not agree about to avoid double spending, and need to throw that data away to avoid economic DOS as storage and bandwidth costs money. But that is the in chain perspective, all blockchain also use a network level that is outside, so network level vulnerabilities bypass the in chain guarantees.
For Git the client decides which branch or other ref to use or which one to throw away.
Proof of stake may be used in blockchains, but without a data type that avoids double spending it is not a blockchain.
Proof of stake may use cleverer algorithms that are not vulnerable to collusion of 50% of peers.
This could be used as part of a solution to ensure write and read availability of solutions to cryptographic challenges like revocation certificates / proofs of compromise of secret keys. This is one way to reduce Sybil attacks that more naive append only logs are vulnerable to (see nothing at stake). Such logs are used in Trillian, CertificateTransparency, sigstore, etc.
Protocols can thus be classified by the answer to the question:
Under what amount of peers colluding for which attacks do which failure modes appear?
Seems for server to server federation this is using IPFS (which is using Kademlia). IPFS itself has no write availability guarantees for content, as those are up to an additional protocol layer.
I’ll be honest, I didn’t pay much attention to cryptocurrencies so I easily might be mistaken. I was under impression that the defining feature of blockchain (as a technology) is that it’s an append-only datastructure that makes it easy to know that it wasn’t tempered with. That is, if I have the latest block and I trust it’s legit, that’s enough to verify that none of the previous blocks was tempered with.
For example, I have my latest Bitcoin block and I trust it’s good, I can download the rest of the blocks and verify on my own they all are good. Same with git, I have my HEAD hash, I can pull the rest of the repo and verify that it’s a descendent of the root commit.
In that sense
repostructure in AT Protocol is the same thing.I see you use “hash chain” to define it. TBH, this is the first time I hear the term. I guess, might be useful to have a separate term for the useful bits for people who want to distance themselves from crypocurrencies.
What you’re describing is a hash chain. Fancier versions are called Merkle trees. They’ve been around since the 1980s..
Bitcoin, I believe, created the term “blockchain” for their usage of a global hash chain with a consensus mechanism for resolving forks. The Wikipedia article I linked to discusses the difference.
I for one don’t want results similar to Twitter/Facebook. Those results have been catastrophic. My takeaway is that having everything you do exposed to the glare of the whole world creates terrible problems. Humans have not evolved the capacity to have social networks larger than about a hundred people.
Depends on use case. I get what you’re saying but let’s consider the case social media was actually good at: letting me find interesting feeds to follow. I don’t consider authors to be within my “social circle” but I appreciate their expertise, insight, writing style, cat pictures they post or whatever. In AT federation I might be missing some feeds if I don’t participate in all indices. Likewise, my content might not reach the widest audience unless it’s in all the indices.
Coincidentally, ActivityPub has a similar issue. There’s no global search. It’s very hard to bootstrap a feed with interesting content.
I’m not sure why everyone’s focused on the “social” part. Very few people chat with their friends on Twitter or Facebook groups as their main mode of communication. I think “microblog” better reflects the best use of public posting in all social media.
I understand why Fb/Twitter would want to focus on the social aspect (“drive engagement”) but it seems users want microblogs more than engagement. At least that’s the impression I get from both AT and ActivityPub. ActivityPub especially since it’s been in use for a while. In fact they actively want to discourage “engagement” the way it’s driven in Twitter, for example.
The vulnerability notifications are junk even working as intended.
GitHub still believes CVSS scores make sense, and therefore it’s a critical vulnerability, 9.8 out of 10, that if you discover there’s an undocumented method called
__private_get_type_id__, choose to implement it manually, and implement it incorrectly, and give attacker a way to control it, then you have a bug. They spammed people with notifications over this.That’s understandable given the incentives. If you give a vulnerability too high a score, some people will patch it unnecessarily and you’ve made some work for other people. If you give it too low a score and an attacker finds an exploit that does more than you said was possible then people who are exploited will complain loudly that you said they didn’t need to.
This is why memory-safety bugs are usually treated as high severity: they allow the attacker to put the program in a state that is outside of the language’s abstract machine. No one wants to enumerate the set of possible states that it could enter (for all possible compilers and compiler flags) and declare that they’re all safe and no one wants to guess and for an attacker to be right.
I have a lot of sympathy with the OpenBSD view that the severity of a vulnerability is a property of the intelligence of the attacker far more than it is a property of the bug.
I think this incentive model applies to traditional, distro-centered security workflow, where there’s OpenSSL-announce mailing list and what not.
But I think recently we observe a raise of qualitatively different workflow, centered around language package managers. Specifically, these days I see “666 critical vulnerabilities” every time I do npm whatever, and then there’s a false dependabot alarm once in a while.
To me it seems that incentives there are fueled by demand for security theater. There’s a vague uncertainty about supply chain attacks, so me must do something about it. Automatically spamming everyone with notifications is quite a lot of something!
In this model, extra noise is exactly the target function we are maximizing.
Yes, but I don’t think the problem in this case was that the memory-unsafety of the bug was more benign than the 9.8/10 CVSS score suggests. The problem is that it happens in a super super niche misuse of that library only, and CVSS has no way to quantify this kind of thing. If this was C or C++ instead of Rust, reporting “if you misuse this hidden, undocumented library API, you can break safety invariants” would probably not even be considered a bug, let alone a 9.8/10 CVE.
Edit: I think what’s missing for me from CVSS is maybe something like an “exposure score” that answers “given somebody uses the affected piece of software, how likely are they to be exposed to this vulnerability?”. Where “this is exploitable in the default configuration shipped by Debian, Ubuntu and RHEL” or something is a 10/10 and “this is exploitable if you really go out of your way to create a weird configuration, but we don’t know of any instances of anybody doing this in the real world” is a 1/10.
I don’t disagree that the bug was the wrong category, I’m just pointing out that the consequences for giving something too low a rating are significantly worse than giving it too high a rating and, with that set of incentives, the system will eventually tend towards giving everything ‘10/10: maximum severity’ rating.
But this ass-covering devoid of common sense is my issue with the CVSS. It’s a broken system with perverse incentives. It’s worse than useless.
I got the impression there is some support somewhere to write coccinelle/semgrep style code matches to check if a security advisory needs action by a usage of the buggy software. I.e. then Dependabot would only notify users of a library that actually use the vulnerable part of the library.
I thought I had seen people talk about Github Advisories / Dependabot using such a matcher for some CVEs. Anyone knows if that is implemented or has a pointer to docs or an example? But maybe it was only a rule for https://github.com/returntocorp/semgrep .
Though then there are denial of service bugs like https://github.com/advisories/GHSA-f8vr-r385-rh5r where for some users of the library there is nothing else to deny. Probably not worth it to make that fact computer legible, just to avoid reading up on a few security issues to know you don’t need to act.
There will always be many responses of “the leopard has not, to date, eaten my face” and “risking a face is well worth it to have a leopard”. Sometimes the answer is simply to decide not to play. Signal will, in the fullness of time, sheepishly admit to a slew of security problems, sharing the complete message stream with various governments, and enact new monetization methods.
The leopard will always eat your face.
Is this based on anything or are you just saying you get the wrong “vibe” from Signal? If so, what would you suggest to replace it? Signal has done a better job at bringing secure, encrypted communications to the masses than any other group or app that I’m aware of, and it’s detractors always seem to have arguments like it feels wrong. And then they typically suggest replacing it with options that either don’t even encrypt basic metadata (like Matrix) or are wildly difficult to use and could never possibly gain mass adoption (like Briar).
There are parts in the security design of Signal that are lacking (though it also did innovate better security in quite a few parts). Signal also fails on some basic security practices, e.g. https://github.com/signalapp/Signal-Desktop/ does have commits and releases that are not signed. I offered to help them specifically with that on their bug tracker, but nobody from Signal signalled interest nor was it fixed in the years since then. Other suggestions that would IMHO improve security they declined with incorrect technical reasoning. I think there are a few of these arguments that are scientifically accurate and would not clash with their anti-federation stance. But IMHO the leopards would still eat your face even if anti-federation is the only issue.
https://github.com/simplex-chat/simplex-chat does read like it has massive security design improvements over some parts that Signal is lacking, however I neither reviewed it in detail nor tested it yet. It seems to satisfy your requirements for suggestions, can you confirm?
Maybe. Signal’s already answered subpoenas in US court (see their writeup here) and they would be in an immense, project-ending amount of legal trouble if it turned out that they were technically able to provide more data, but chose not to reply. I don’t want to accuse you of FUD, but I do want to point out your lack of evidence.
Technically OP didn’t say decrypted messages nor past message stream, which leaves the stream of still encrypted future messages (and their metadata). If the signal organisation or individual employees are being compelled by a court or otherwise under duress to modify the servers to share this, then no technical mechanism is in place to prevent this. Such a protection mechanism is practical.
Furthermore getting the cleartext is also possible in a similar way. None of the signal clients are protected against signal being compelled to create an update that exfiltrates the cleartext of old stored or new messages. It could be prevented by the combination of having security reviewers in multiple jurisdictions, using verified reproducible builds, and using an updater fetching from an observed global append only log / binary transparency.
Is this sufficient evidence for you that it is possible?
AFAIK Signal has no willingness to accept help to implement either of these protections nor willingness to implement themselves. I’m interested in contrary evidence.
Can anyone link the 3 patches submitted to lkml mentioned in the paper?
I had trouble finding them from the little information that is in the paper. That the search on lore.kernel.org doesn’t seem to have a full text index makes this harder.
We don’t know where those patches are and they are not submitted from umn.edu emails. What follows are only speculations.
https://lore.kernel.org/linux-nfs/YIEqt8iAPVq8sG+t@sol.localdomain/
I guess they must be in there? These are commits from the main author. https://github.com/torvalds/linux/commits?author=QiushiWu
I don’t get it.
How would an open (idle) TCP connection still request updates over HTTP? The only contrived example I can come up would be websockets…
Also not sure if the author ever heard of TCP socket timeouts and how reliably unreliable they are.
It can be used to track you across websites, i.e. it is a short lived super cookie. Which also means that the state separation to protect against super cookies should help.
Even if it does not close the connection, such a protection would need to not reuse the connection for a different website with separated state. Also clearing state (“cookies” in UI speak) for the website for which the connection is left open needs to from then on never use this connection until it is closed at the normal time out. (Closing the connection before the normal timeout sends the information of this user interaction to the server, but I’m not sure if it is worth it to prevent that, so maybe it is fine to just close it early.)
I don’t know if this is all correctly implemented in Firefox, might be worth it to test and report any deviation as bugs.
I still don’t really follow. How would anything with cookies (HTTP, stateless) work via a shared TCP connection. I’m completely missing the point where this is not just a hanging connection (where the website under certain circumstances would assume you’re there for 20min longer than you are) and nothing else.
Also in the super cookie you mentioned wouldn’t the problem be the reuse of the connection and not the “not closing”?
Yes, it is the reuse. To reuse connections is the reason browsers doesn’t close connections immediately in the first place. Also anything where there is a noticeable behaviour difference, like closing the connection early on some user interaction where it would otherwise idle longer until close.
Half closed TCP connection, sometimes called hanging, have a different state than fully open, idling connections that can start to transmit at any time again. Normal http-cookies are per request, multiple requests can share the same connection. With HTTP keep-alive in serial fashion, with HTTP version >2 generally in parallel. Super cookies do not rely on http-cookies, sometimes they only track users by measuring timing differences.
If you never use that web browser again then it makes no difference. But if you reopen it, the process was not terminated (otherwise the connection would have been closed by the kernel), the connection is still idle and then gets reused.
When the connection to a third party gets reused for a request that is for a different first party than the one it was opened for, that can be used for tracking across the web.
The author omits that the SSPL doesn’t work for the stated purpose in the article, MongoDB, or Elastic. (As discussed before: No need to accept for use. Not practical to comply with when accepted.)
The ACSL also doesn’t work for its stated purpose: As a simplification take capitalist as someone setting terms for workers where that someone controls more than 50% of the capital. Lets for example take a manufacturer of clothes who needs software to run the cutting machine for cloth before sewing. They create a company that is fully worker owned, then rent all the machines to that company and provides any other capital they need to operate under the renters conditions. Such a company is clearly operating under terms set by a capitalist, but is able to use the software under this license. The authors of the ACSL seem to recognize this. It seems to be more intended as art than for purpose.
Many licenses that say they want to be better than open source for some purpose, fail at being fit for that purpose, even more than one of the established license would. I don’t think that would be inherent in such a goal. Though some goals are much more complex to create mechanisms for than others, so that is a reason why people who are serious about such goals usually don’t start with a copyright license.
Even with its holes the AGPL might still be better than the ACSL, if your intention is to ward off capitalists, as it has a share alike requirement, which the ACSL lacks. Having a license that plugs the SaaS-wraps-FLOSS loophole of the AGPL seems worthwhile either way.
A license that you can’t comply with isn’t a license. This article entirely ignores that.
The SSPL is not a license that is practical to comply with while running the software as a service. Neither MongoDB nor Elastic themselves are able to comply with their own license. Nor are they working on being able to.
Nobody can currently run a SASS DB offering with only open source. There will be software in your USB-C cable, your network card, your ethernet switch or something like that. You can’t buy a version of every hardware needed, that works only with open source software.
Yes, the reaction from OSI also doesn’t lead to a practical open source license that plugs the SASS-wraps-FOSS loophole. People with power in OSI have been against stronger copyleft.
I do not fully understand the difference between SSPL and AGPL, can someone explain it to me? Is AGPL not considered open source? I think this may be the question to Drew?
If I understand correctly SSPL would force Amazon to open source anything that touches ElasticSearch eg. their entire platform? Is that right? So that would mean that SSPL violates freedom #0.
You can check which licenses are considered legitimately open source here: https://opensource.org/licenses/alphabetical
Here’s a post by the OSI clarifying about the SSPL: https://opensource.org/node/1099
And here’s the definition of ‘open source’: https://opensource.org/osd
I’m unsure that the OSI can be treated as honest brokers here. Open Source means what it says, not what OSI say it means, they can try to be a gatekeeper if they want, but noone’s obliged to take them too seriously.
Take this spew of nonsense (for example):
That’s just incorrect, both factually and legally. Saying “license mets the open source definition” or “license is approved by the OSI” would both be deception. Saying “I believe this license is open source” is not.
“I believe X” is mostly not a testable assertion, also it could be true while X is wrong. It is also not that interesting to know what MongoDB and Elastic are believing, it is interesting what they did. Thus: What could happen if one were to use software under the SSPL? Do MongoDB or Elastic use software they license under the SSPL?
A license like SSPL that nobody can comply with is not a license for you. Thus claiming its an open source license is deceptive. See https://lobste.rs/s/t9kcgy/righteous_expedient_wrong#c_swk45k .
Maybe I’m missing something, but I still don’t see any details in that posts, or the links from it, what disqualifies the SSPL (how does it differ from AGPL?)
The post links to a mailing list thread which has further discussion about why the SSPL was not accepted as an open source license.
Thank you, this clears up my initial misunderstanding of what SSPL requires.
Under what condition and how can a client detect that another client noticed and proved that the log gave an incorrect answer? When does this other client do the additional work to notice this if not every client does that work?
Some incorrect answer of interest: giving a different answer to some clients (split view), an entry that was there before isn’t there any more (truncate), missing entry (as not every client validates the full log), response with an additional entry not seen in the log when walking it, a write was tried but is not seen on trying to read it.
I must be missing something. This claims that it addresses the type of supply chain attack that bit SolarWinds, and the load bearing defense here appears to be digital signatures. Didn’t the malware that got introduced into the SolarWinds product have a valid digital signature?
Maybe I’ll spot what I’m missing after some more coffee.
It’s probably too subtle for Before Coffee o’clock.
I recommend reading Taylor Hornby’s Triangle of Secure Code Delivery.
With Gossamer, it isn’t just signatures. It’s also a transparency log and third-party verification (thus, attestations).
What this buys you is more than “don’t run unsigned code”. It’s also “don’t run code unless it was reproduced by $trustedThirdParty from the source code” and/or “don’t run code unless it’s been reviewed by $trustedVendors” too.
This adds more mechanisms for mitigating supply chain attacks, as well as unavoidable transparency that prevents stealth operation.
Hi Scott! Been a while :) How does one find developer pub keys in Gossamer?
A few ways come to mind:
/verification-keys/:provider-name)But most people will use the easy button:
This returns an array of strings representing the (hex-encoded, IIRC) Ed25519 public keys currently trusted by the universe.
(This actually does up to two of the things I listed, under the hood, depending on config.)
So does trust in a provider’s keys basically come from votes in the transparency log? If so, whose votes do you trust? Is that manual?
New keys are signed by your old keys.
Your first key is sorta TOFU but with transparency (since it’s published in the ledger).
There is nothing approximating WOT or key signing parties. Looking at it through the PGP lens will lead to confusion.
To verify keys in advanced threat models, you need only confirm that peers see the same view of the ledger. You can compare Merkle roots (Trillian) or summary hashes (Chronicle). Or the lazy way: query Gossamer Servers in addition to running the Synchronizer locally.
(These ledgers are centralized-publish, decentralized-verify, so we don’t need to deal with distributed consensus.)
Not in the sense that you need to find agreement, but you still need to notice when you don’t agree to be able to check if this disagreement is a compromise.
Is there even a failure that a log without distributed inconsensus detection can detect that non-chained simple signatures won’t provide?
That makes sense. FWIW, I have an easier time considering the merits without thinking about the SolarWinds mess. That combined with my earlier lack of caffeine obfuscated it a bit for me.
I like the transparency log, especially.
Now we need reproducible builds in a widespread way to give this some teeth.
One of the defined attestation types is
reproduced(i.e. for reproducible builds) for this exact reason.Getting the various tools to cooperate to that end is such a headache.
It feels like a relatively small budget spent on sponsoring an easy/reliable way to do it for C and C++ projects that use cmake and autotools would have an outsized impact.
Well, this is starting with PHP first, not a compiled language yet :)
Add Java to it and you get a pretty decent amount of software more secure.
Combining ZFS and Linux is a GPL violation anyway, so Linus could not include it in Linux without violating the GPL unless Oracle gave explicit permission (or an exemption) for this, as Linus alluded to.
For more details, including why Canonical is violating the GPL by distributing ZFS in Ubuntu, see https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/ (disclosure: I work for Conservancy).
That’s a strong statement. From what I understand, it’s not allowed to distribute Linux together with ZFS, but building ZFS yourself and using it on your own machine is not a GPL violation, right?
I’m with you there. But I don’t think anyone here has asked him to include it. Rather, this seems to be about Linus making changes to the kernel that make it harder to get ZFS to work on Linux.
Distributing a combination is not the only problem when dealing with the copyright of ZFS on Linux: While I don’t like it, one can also be held liable for copyright infringement that others committed, e.g. by inducement of it. That means this is also a question for when one were to contribute to or distribute ZFS on Linux without combining it.
On a more general matter: It is said, though disputed, that Bryan Cantrill ( on here as @bcantrill ) was one of the biggest proponents of the CDDL. If he were to read this I would like to know from him (and anyone contributing under CDDL, if you care about having/giving a license):
The relevant Wikipedia pretty much answers your questions, including quotes from @bcantrill. https://en.wikipedia.org/wiki/Common_Development_and_Distribution_License
#3 CDDL is generally not incompatible with any OSS license, except MAYBE the GPL. The FSF thinks it’s incompatible, and Linus clearly has a perspective here, but he isn’t really saying it’s a Legal issue, mostly an Oracle is evil issue (which everyone already knows). See the above wikipedia entry for the details. But either way it’s never been tested in court, so it’s still unknown if it’s actually incompatible. Certainly the spirit of both GPL and CDDL licenses are compatible.
Plus CDDL is an interesting license as it’s file based, i.e. it’s attached to individual files, not to a project as a whole. Which makes it unique in the OSS license tree. So you could only make new files in the repository/project dual-licensed. You can’t really change a CDDL licensed file unless you also happen to own the copyright(s) to the entire file, which in the case of OpenZFS is now quite broad, and not limited to Oracle alone.
Basically there is OpenZFS which everyone uses (across multiple different platforms), except Oracle, which nobody uses (unless forced, for non-technical reasons). Oracle can not import any of the OpenZFS changes back into their tree (legally speaking) because the Oracle version is no longer CDDL licensed.
OpenZFS has a lot of awesome features that Oracle can’t import into their version. The latest new feature Oracle can’t import is data encryption on disk.
That the GPL and CDDL are incompatible is mostly legal opinion at this point. Certainly the Conservancy has an opinion and the FSF has an opinion, which coincides with your statement of “fact”, but it’s never been tested in courts, and plenty of other lawyers have an opposing viewpoint to yours, so much so that Canonical is willing to bet their business on it. More about the various opinions can be found on the CDDL wikipedia page: https://en.wikipedia.org/wiki/Common_Development_and_Distribution_License
I think most people can agree that in spirit, both are compatible, to some degree, but there is a difference in that GPL is a project based license, and the CDDL is a file-based license(which makes it unique).
I don’t think either perspective can be called fact until the various court systems have ruled one way or another, and I don’t really see anyone itching to find out enough to dump a team of lawyers in front of the court.
I’m certainly not going to say you are wrong, and Linus has made it very clear he has no intention of incorporating OpenZFS into the Linux tree anytime soon, but I think even if everyone on the planet agreed legally that it could be incorporated I would like to think he(and many others) would hesitate anyway. The Linux tree is already pretty giant, and OpenZFS’s codebase is no slouch either (it’s in the millions of LoC). Plus, there isn’t really a huge benefit in incorporating OpenZFS into the kernel tree, since OpenZFS is cross-OS (Unix, BSD, macOS, Windows, Linux, etc) and the Linux kernel … isn’t.
One of the comments on the linked site state
What exactly does EXPORT_GPL mean? I’m not a kernel dev..
It’s a signal from kernel developers that they expect anything using EXPORT_GPL to also be GPL’d code. it’s a legal stance, and not a technical one.
i.e. if you use EXPORT_GPL, then they expect the GPL license (sometimes called “infection”) to apply to your code as well. If you use just EXPORT, then they don’t expect the GPL license to apply to that code.
to be clear: where they is the kernel developers.
Symbols which are EXPORTed are considered free to be used by any (out of tree) kernel module, irrespective of the license of that out-of-tree module. “EXPORT_GPL” symbols are intended only to be used by modules licensed under the GPL.
There is no such permission given in the license of Linux. I remember at least one Linux copyright holder explicitly saying multiple times that they reserve the right to sue for copyright infringement irrespective of how the symbol is marked.
While EXPORT_GPL shows that there is at least one person who reserves the right to sue for copyright infringement when using in a module under an incompatible license, EXPORT doesn’t tell you anything more than the text of the license (GPL 2) in itself. EXPORT is not EXPORT_MIT or something like that.
In my opinion google cloud platform UI sucks like it takes so long to get service up and running. I remember one time I met a someone who worked at google said the same thing since it’s new in the market and trying there best to make the services better. But on the other hand Amazon Web Services is really smooth and it’s really easy to get started with it. I haven’t use other cloud services but I’m sure each one has there pros and cons
Has anyone tried openstack by red hat
Isn’t openstack by Canonical?
I set up a small openstack instance this past summer and while it was a royal pain to set up it seemed fairly well thought out. The performance was not amazing but not outside the expected performance of an cloud platform. The user experience is about the same as every other cloud platform after everything is set up. One thing I never got completely sorted was how to set up metrics. There’s probably a service for it, but I couldn’t figure out how to get a dashboard with actual (as opposed to provisioned and unused) cpu and memory stats.
See above. It’s an independent open source meta-project contributed to by many large players, but its popularity is on the wane in favor of containers which are much easier to manage.
Openstack is neither redhat nor canonical. It’s an open source project backed by a number of large vendors, but, to be honest, every single time I talk to anyone who’s implemented it in their day job, they said the same thing: Initial build goes great but the upgrade story is a nightmare, and it’s actually a constellation of separate largely independent projects with varying levels of contribution by developers so the amount of polish varies.
The industry is trending towards container based solutions, and RedHat has a very nice container clustering solution for large scale deployments called Openshift.
No skin in this game since I don’t use any of them, just passing along what I hear from folks who do.
OP mentioned OVH which uses OpenStack: https://www.openstack.org/marketplace/public-clouds/ovh-group/ovh-public-cloud
Wikimedia runs OpenStack for its community: https://wikitech.wikimedia.org/wiki/Portal:Cloud_VPS
I’d recommend OpenStack based over proprietary clouds, but I’m biased. But if one manages an OpenStack installation badly, the experience can be bad.
This thread mentioned containers (OpenShift is based on Kubernetes, which is for scheduling/orchestrating containers) which some people run on top of VMs (I have seen this with OpenShift on OpenStack Nova which uses KVM but also others). If you need VMs, in the long run I’d recommend the other way around: VMs in Containers. Two interesting projects in that space: KubeVirt is more light weight and runs KVM in Kubernetes. Airship is a way to install and update Kubernetes which also can run among others OpenStack in that Kubernetes.
TL;DR: add an Incorrect flag if that makes more people vote; but that won’t be enough, the scoring algorithm needs to be fixed, needs to be made more lobster like.
Incorrect submissions are also spam. Spam is something unsolicited. Incorrect submissions are not explicitly solicited. Therefore they are also spam. That doesn’t require that you can identify a thing that is being promoted.
You mentioned reputable sources but did not say how you define reputable and whether that is independently testable. Reputation can not replace testing an argument, but if done correctly it can help coordination to find things that are worth testing. I consider incorrect thus a more useful concept here.
What is the goal of flagging? Some reason may be a negative score to filter <0 and/or some admin reaction. Anything else?
Many incorrect submissions still keep a positive score, even after that is shown in the comments. A more specific flag than spam will not necessarily make them go negative. That is not a reason to not add an alias or more specific flag if that makes more humans vote at all on a story.
It happens that incorrect information is scored high on this site. One might want to use a better reputation algorithm to make it easier to find scientifically correct submissions and not waste time with things that are incorrect. One that improves quality over time without resorting to authority or majority-rule. It needs to work on something more specific than one score/tally, like if a tag applies (or even a more expressive assertion). It would require calculating the reputation individually for a user based on who they trust to use a tag correctly. Which is a more lobster like approach, as they don’t form a shared hierarchy but each their own view of it. The trust calculation needs to be able to differentiate between trust for different tags. This trust between two humans needs to be calculated based on tags/assertions they put in this system, not directly. It needs to be able to keep by user choice some input private. It needs to take into account if people acknowledge their errors. (To answer if I make an adversarial collaboration with this person.) It needs a way to avoid Sybil attacks. Explicitly tagging things as “correct scientific argument” is needed to make the goal more obvious and to not exclude fiction, jokes, and allow any categorisation goal. It should be able to tag only a part of a submission.
A good collaborative categorisation system makes it possible to take into account when people agree on a specific assertion without requiring agreement on other or a more general assertions. (The current one fails this by requiring agreement on a the very unspecific “up or downvote”.)
It looks like you don’t want Free Software, but a communist revolution.
You can’t have one without the other.
Your above assertion is not specific enough to test or falsify.
Karl Marx didn’t know about falsification (thus science) yet as that was only described after his death. You could write arguments that others can check instead of merely taking your word for it.
In the article you say:
This is circular reasoning or perhaps a tautology. You give the conclusion as a reason for the conclusion.
Software for humans (as opposed to only for some humans but not others) is required to be more scaleable than merely commercial software as there are more than 7G of them. Commercial software merely needs to work with enough humans to extract money, it can ignore the rest.
What is more important to you: Human needs/rights or the inability of the software to be used by corporations?
Is a communist revolution your goal in itself or is that only your suggested solution? Are there some goals you have where if some other idea could reach them, it would be fine for you not to get a communist revolution?
I didn’t mention Marx in this essay. However – your statement is incorrect. Marx wrote during the industrial revolution, & his explicitly stated goal was to remove the woo from existing socialist movements (like the fabians) by sticking to rigorously scientific analyses of historical economic data & construct falsifiable models of economics. This is what is meant by the term ‘historical materialism’: an attempt to bring economics out of the realm of Smith’s just-so stories & into the realm of science, submitting it to the same rigors that were then being applied to thermodynamics.
(Last I checked, the scientific method was attributed to Sir Francis Bacon, a few centuries before Marx was born. The nineteenth century was the absolute peak of the kind of scientific reasoning you describe – named and documented by Popper a half century after its moment ended in the wake of the virtual demolition of the analytic movement in philosophy by Godel & Wittgenstein.)
No, I just thought that the incentive misalignment was so obvious that I didn’t need to specify it.
This point is fair, so long as you assume the existing division between developer and non-developer. I’ve written at length elsewhere that this division is arbitrary, problematic, and a form of rentseeking, & ought to be abolished. Since you haven’t read those pieces, I can’t blame you for thinking that this is a flaw in reasoning.
Human needs. (After all, like the rest of us, I write software for corporations all day. I maintain that it is problematic in the long run, but in the short run it is necessary for my own survival.)
I’m not really an advocate of revolution per-se. It’s messy & often ineffective, since military structure, while necessary for war, runs counter to an equitable arrangement of people. Gradualism has other problems, but luckily there are solutions that are neither revolutionary nor gradual. My own preference is the scheme outlined in bolo’bolo: the construction of alternatives, independent of existing systems, which people can move to freely. Popular alternatives starve incumbents of labor & resources. In the late stages this is almost guaranteed to result in direct attacks, but by that point, if things are managed well, the incumbents will be too weak to do much damage.
Let me repeat my first sentence with a different focus:
You didn’t refer to a specific model of economics.
If you specified a correct economic model and matching implementation, that isn’t yet sufficient for that to follow. For your claim, you’ll need to specify properties without which Free Software can not occur. With enough precision so that it is easy to say if something matches those properties or not.
One can state something falsifiable without explicitly having defined falsifiability or deciding on using it for demarcation to non-science. I only mentioned Marx to be a bit more specific than mentioning the word communism. Marx certainly did make non-falsifiable claims in addition to falsifiable ones.
AFAIK Sir Karl Popper defined falsifiability long after Marx was dead and suggested anything not falsifiable is not science. Francis Bacon didn’t require falsifiability.
There are certainly obvious cases of incentive misalignment. What is not obvious is that in all past, current and possible future systems in our reality, “users and corporations do not have aligned incentives”. (For it to be falsifiable you need to specify how to detect a corporation. Does Alice and Bobs collusion constitute a corporation?)
Doesn’t matter under what economic system or how the labour on that software is organised. That does not change that a human would need to be able to run compatible protocols together with over 7G humans for them to be able to not exclude some of them. Otherwise: Sorry, no internet1 for you, its full. Make your own internet2, which won’t fit everyone either. So some won’t be able to directly talk to some others. This would create the opportunity for those in both internets to seek rent for forwarding. Therefore the non-scalable property enabled what you said to avoid.
Unscalable software would compromise the rights of some humans. Thus it does not serve your stated goals.
You’re applying a lot more rigor to a flippant response (to someone’s flippant comment) than to the article itself, wherein I specify exactly what I mean by free software and exactly how it’s currently being prevented & a few ways to close the loopholes that are being exploited.
The goal of free software is to align the incentives of software developers and software users by making them the same group. (If we want to bring Marx into this at all, we have a convenient place to do it: he defines communism as any state of affairs in which the incentives of management and labor are aligned because management and labor are the same group. I wasn’t drawing on Marx in this essay but on Debord, so outside of this point that’s a much more suitable comparison to make.)
The labor of software use always falls upon individuals, so user incentives are best defined by individual incentives. Because almost all individual software users sell their bodies to corporations for at least eight hours a day, during which they are required to perform actions in the ways demanded by corporations rather than in the ways they would naturally perform those actions, points of friction become biased based on standard procedures. It is only in the interests of a corporation to lubricate the points of friction that occur when performing corporate-controlled work, and then only when the people who encounter those points of friction are insufficiently disposable.
Sure, as does everybody. And, Marx was wrong on a number of points (among them, he thought that ‘capitalism with a human face’ was impossible & so thought that the internal contradictions of capitalism would cause it to collapse substantially faster).
He had, as an explicit goal, to be scientific – by which he meant creating systematic models of the entire relevant portion of the problem & testing them against both historical data & new experiments, eschewing metaphysical ideas and wishful thinking in favor of mathematics & mechanisms, and emphasizing the importance of revising models when they have failed to be predictive even when the resulting new model is complicated by this collision between theory and practice. In other words, in terms of Popper’s idea of science (which itself is fairly controversial), Marx’s economics scores higher than many current fields (including practically all of medicine outside of drug testing).
If we privilege the needs of individuals over the needs of corporations, then any time the two come into conflict and the corporation wins, it is an unnecessary tragedy. When their needs are aligned, it is irrelevant: the equivalent number of individuals coming together in a different structure would have the same power to fulfill that need. When they are not aligned, corporations tend to win, because that is what corporations are for.
The usual way will suffice. A corporation is a legal entity that can hold capital and resources the way a person does, and can usually be sued in the way a person can be, in such a way that it forms a buffer between an individual and liability. A corporation continues to exist so long as it periodically pays the government a registration fee, unless it is dissolved by its owners.
This means a corporation always has an incentive to accumulate capital, because accumulated capital is capable of protecting it from all possible risks, & any mechanism for accumulating capital that does not risk losing more capital than the company can afford makes sense (i.e., fines for illegal activity are part of the cost of business & bad PR can be offset by marketing). It also means that the owners of a corporation are incentivized to dissolve a corporation & run off with its capital if they think it’s no longer doing its job. A corporation is a disposable shield that is immortal so long as you keep feeding it, but gets hungrier as it gets bigger: an ideal tool for protecting individuals from the voracious maw of the market.
I’m not opposed to the concept of protocols. I’ve got a problem with monocultures.
Software scalability matters a lot with regard to centralization. If one organization owns all the machines for doing a thing, then those machines need to be efficient, because the margins are the difference between skimming enough profit to survive and slowly bleeding to death. In a decentralized system, most of the things we mean by scalability don’t matter: one person isn’t doing maintenance for a thousand machines but for one machine, so it makes more sense for that one person to be comfortable with their one machine than it does for all thousand machines to be interchangable; one person isn’t moderating the feeds of all of malaysia, but instead, everybody tends their own moderation and perhaps helps out with the moderation of their friends.
I’m ultimately less interested in opening up low-level protocols than front ends, because the shape of behavior is controlled by the adjacent possible. I go into this in detail in other essays, but where it intersects with this topic is: when you make software for employees, the people who use it are biased toward acting and thinking like employees, which is a very narrow slice of all the different hats one could wear; likewise, when everybody runs the same software, they think more alike, because their imagination is shaped by their habits.
We know from observing users that they are capable of using an extremely flawed folk-understanding in conjunction with trial and error to produce effective, if convoluted, mechanisms for getting things done with inadequate tooling & inadequate documentation. In other words: all humans are born hackers, and the difference between somebody who rigs up some incredible hairball of an excel spreadsheet to do something & somebody who does it in perl is not a matter of inherent ability or even really skill but of access to the ability to imagine better tooling (i.e., a matter of exposure, education, & identity). Just as MySpace’s willingness to host arbitrary CSS led to often-messy but incredibly personal and expressive profile pages, making the resources available and visible by default to everyone to modify all the code on their system will result in even self-professed ‘non-technical’ users adapting their systems to fit their preferences in extreme ways – and the more available we make that ability to imagine a better fit, the greater variety & the closer fit we will see. (In other words, this is a natural extension of free software: rather than collapsing the distinction between ‘a developer’ and ‘the developer’, truly collapse the distinction between ‘developer’ and ‘user’.)
Even opening up the whole system, we should expect to provide reasonable defaults, because writing an IP stack is an acquired taste – I don’t expect many people to dig that deep when optimizing for a real-world task. Even so, monocultures of implementation are dangerous in many ways, so we ought to have more fully independent reimplementations of just about every protocol. If a protocol cannot be trivially reimplemented, then it has failed at being a protocol. Vary every behavior not specified with ‘must’, bring out the nasal demons, etc: the ecosystem will improve because of it.
Computer software is made for and by people who already like computers, and this prevents problems that are obvious to other groups from being solved. Require less initial buy-in at the level of software creation and you’ll get computers that are worth liking.
If centralized social media has taught us anything, it ought to be that people don’t really want to open themselves up to being talked at directly by seven billion strangers, because scale of direct contact amplifies the power of griefers and low-effort shitposting a lot more than it amplifies useful forms of communication.
SSB has the best model I’ve seen in action. You’re responsible for managing your own feed, but visibility is based on the existing social graph & is asymmetric. Basically, so long as you don’t follow pubs, you can keep the presence of hostile randos looking to bother you down to a dull roar without putting the labor of that on some overworked moderator. Visibility & access follows the usual course of human connectedness, & tactics created by a fully flat network like sealioning and swarming don’t really work.
Lots to chew over here. Thanks for taking the time to write!
The author gives no alternative to the web of trust or their arguments against it do not hold up during scrutiny.
Long term identities could be built on rotating keys. Yes, this is one of the many areas where PGP lacks (with its identity key rotation not being user friendly). This is also where Signal lacks (binding long term identity to the phone number only instead of allowing chaining of keys).
Yet they give no details in which way it doesn’t work. For finding the key of someone you haven’t met, the web of trust idea improves security over trust on first use. Man in the middle attacks work for trust on first use, but don’t on web of trust.
They just mentioned web of trust in the same paragraph… What do they think of people who do use the web of trust?
Yes the usability and privacy of web of trust can be improved. See e.g. https://claimchain.github.io/ . Getting introduced to other people is something many people do in real life and did before the Internet existed.
At this time, it’s up to the proponents of web-of-trust to prove that it’s a workable concept, and not a theoretical construct that doesn’t work in today’s world.
The recent brouhaha over keyservers shows that the infrastructure at least is sorely lacking.
I personally believe it is a better option than centralized services (remember StartSSL ?) if you use TLS client certificates – see weird CAcert – or OpenSSH keys – see Monkeysphere.
Some open-source projects use Web of Trust, for example Arch Linux or kernel.org. IIRC Debian also requires their developers to have “strongly connected” keys.