nightpool

> We are unable to make cohost open source. the source code for cohost was the collateral used for the loan from our funder.

I never really understood this—what is their anonymous and secret funder going to use the source code for Cohost for? They've been very closed lipped about that part. Oh well, I guess we'll find out soon.

That's not what RealPage did. RealPage (in landlord's terms) "uses proprietary data from other subscribers to suggest rents and term"—not just publicly available data. Additionally, there's a market impact level to this. When you control 70% of the market, you're a monopoly, regardless of whether you're controlling market prices because you're a landlord or because you're just telling the landlord what price to use. The law ~says that you cannot control 70% of the market.

So, yes, if you sell a hosted version of your program that sets prices for 70% of the market and then use you contracts and incentives to police landlord's compliance with your program (another key feature! if RealPage was just providing the data, they would have been less of an issue, but they were also using financial kickbacks to ensure landlords kept their prices high), you are forming an illegal monopoly or price fixing cartel.

Seems like I got killed by a glitch that teleported me off screen and then marked me as "killed by Unknown"

This is really, really cool, but I'm a little disappointed that there's no credit for the channel / video you're watching when you click on the (i) icon—only a link to your own credit. I think if you're going to credit yourself, you have a moral obligation to credit the people who made the content you're highlighting as well.

these are 12 month numbers

> it is a kestrel requirement to do ssl termination

Couldn't you just pass it x-forwarded-proto like any other web server? or use a different self signed key between nginx and kestrel instead?

The CPI inflation rate gets lower when you include food and energy, not higher. OP simply chose the higher number (3.2) for the HN headline, not the most accurate one (2.9, which includes food and energy)

The World Gold Council says:

> If every single ounce of this gold were placed next to each other, the resulting cube of pure gold would only measure around 22 metres on each side

So that can't possibly be right, you must be off by a factor of 10 or so at least—Wolfram Alpha says a 30m diameter sphere.

What do you see as the intended reasons with no other solutions?

Sounds like you need to get better reverse proxies...? Making your site traffic RELY on the fact that you're using different certificates for different hosts sounds fragile as hell and it's just setting yourself up for even more pain in the future

I know next to nothing about WordPress and haven't used it since I was very little, these opinions just come from my general knowledge of web development, especially trained by my 5 years of Rails experience. Never underestimate the power of a good framework to illuminate the ways in which bad frameworks fail.

The Trinity Railway defines on time performance for trains as arrival within 5 minutes of schedule[1]. It's not materially different from the Swiss standard.

1: https://ridetrinitymetro.org/wp-content/uploads/2022/08/Serv...

After some thinking: I think a large part of the blame here also falls on the Wordpress documentation. It says that nonces should "never be used for authentication, authorization or access control", but it doesn't explain why. In actuality, nonces seem like they could be a very useful way to authenticate certain actions when a classic authentication session is not available (for example, when sending a user an email that allows them to take an action that they may view on another device or without an existing session, like a "password reset" form, or when authenticating a webhook callback). The fact that plugin developers aren't given enough info to reason through the security implications themselves makes these kind of mistakes more likely, and it also leads to this "cargo cult" security mindset you see in the article where any use of the nonce value magically makes your plugin less secure, regardless of the context. Instead of reasoning through what actually caused the 3 vulnerabilities found, the author just blames the problem on nonces.

And another thing, if Wordpress developers really only want nonces to be used for CSRF prevention alone, why are they so complicated and so exposed to the developer? A more simpler and less "security by complexity" based approach would be to just e.g. use a cookie with a random value and a hidden field with a random value and expect them to match, like Rails does. If these nonces didn't have all of this "hash the user's ID and session token and the current action and add in a 12 hour lifetime" complexity, then developers would be much less tempted to use them for authentication. Additionally, why is the "verify" function exposed to developers at all, instead of being part of a higher level function like "register ajax route" or "register post route"? These are all weaknesses in architecture that make the misuse of nonce values for things beyond CSRF tokens more likely. It's not enough to just write a few lines of documentation and say "There we go, I've secured everything now!". You need to actually figure out what use-cases people are using these functions for and then figure out more secure-by-default ways to address those use-cases, otherwise you're not going to make any progress.

I'm not sure I really understand the weight this article gives to "nonces"—from an outside perspective, it seems like writing an titled "Exploiting authorization via cookie on Google.com" when you've found a simple XSS. In each case, the problem isn't the nonce itself, but rather the fact that developers are 1) allowing arbitrary file uploads with insecure sanitization, 2) embedding a secret value in frontend JSON blobs that any user can read, or 3) a completely unrelated SQL injection vulnerability.

For #3 especially, it's pretty confusing to single out nonces as especially vulnerable. Any secret defined in wp_config would have been similarly exposed by this exploitation method. For example, the SECURE_AUTH_KEY or the LOGIN_KEY. If you had found an installation that put those values in the database (probably common for multiuser installs), would you have instead written an article that claimed "Wordpress logged in sessions should never be used for authentication"? Or that wordpress auth sessions are "often misused by developers"? Similarly with #2, you make a haphazard effort to tie the improperly sanitized uploaded files back to nonces by saying "a nonce is required to acces the uploaded file", but that really doesn't have anything to do with the vulnerability itself—many users on wordpress installs are required / expected to upload publicly visible files, or files visible to their own user. Or even files visible to the administrator! The method of authenticating access to the files has nothing to do with the vulnerability itself, it was only a small piece of trivia required to properly exploit it in this specific plugin in some cases.

> Unless the operating system for iPhones is open source and one can verify which version they have installed

There are a lot of security engineers out there reverse engineering Apple's iOS versions and payloads, especially ones installed on the phones of activists and other dissidents who may be under government surveillance. While in theory Apple could build a compromised OS and serve it only to a single IP or whatever, the reputational risk if they were to be discovered would be enormous. Compared to when the processing is happening on Apple's servers, where it's impossible to tell for sure if you're being wiretapped, there's just too much of a risk of detection and tipping off the target.

No, the Apple article says that they're using the much faster and easier to implement k-anonymity strategy

Second: Google Recaptcha Enterprise can use Homomorphic Encryption to check whether your password has been compromised (searching the set of all breached passwords without disclosing which individual password you want to check)

Now, in practice, HaveIBeenPwned does the exact same thing with a k-anonymity scheme based off of MD5 collisions, which is wayyyy easier in practice and what most people actually deploy, but the Google thing is cool too.

> but do they really care if the organization makes a promise about a secure execution environment in the cloud?

Uh... demonstrably yes? No "secure execution environment" is secure against a government wiretap order. FHE is.

I don't think that's accurate—homebrew specifically says that it only uses the .linuxbrew directory when a formula contains a hardcoded path (which it scans for), and only if you choose not to install it from source.

So, based on the responses from the maintainers, for the .linuxbrew directory to be used, you have to satisfy 2 conditions:

1. you have to be installing one of the ~10% of formula that isn't trivially relocatable.

2. you have to be using a precompiled binary (which it seems like homebrew is smart enough to not do if condition #1 fails and you're not using sudo)

Obviously Southwest is not using Windows 3.1, and you should probably be thinking hard about the trustworthiness of any outlet or article that repeats that claim: https://www.osnews.com/story/140301/no-southwest-airlines-is...

Setting aside whether or not I agree with the premise that smaller dependencies are worse for building system binaries (I think Nix provides a compelling counterargument), how is vendoring Rust dependencies "like C" (the same way Firefox and the kernel do) a regression from building C? All Linux dependencies are already vendored, and even without access to crates.io, getting access to Rust's language features is still a Pareto improvement over C, not a regression.

What? You think that Mozilla devs would think about adding your domain to the whitelist of domains allowed to install extensions if you just asked nicely? That would be insane from a security perspective.

Already addressed in the article

> it's so much of a regression for building systems compared to C.

huh?

Article is riddled with inaccuracies (crates are not precompiled, they're downloaded in source form and then built locally), and only barely seems comprehensible. The topics they string together and the way they relate to each other (comparing Rust to BSD?) makes very little sense, and it makes me think the article was generated by AI or something similar.

Reading the linked report: https://exposetobacco.org/wp-content/uploads/STOP_Report_Add... it seems that the foundation was used specifically to fund think-tank-like outputs obliquely advocating for PMI's line of "heated tobacco products"—an e-cigarette-like product that has been shown by regulatory agencies to be identical to human health as smoking a real cigarette (since it not only contains addictive nicotine, like a normal nicotine ecig, but also the entire tobacco leaf itself, leading to similar rates of smoker cancer, secondhand smoke symptoms, etc, even though the different combustion processes means they don't create as much visible smoke or odor).

These HTPs have become very successful in Japan, and although PMI publishes most of the research they use to argue for them directly (for example, showing they have 3x less particulates than cigarettes, ignoring that they have similar health outcomes), the FSFW seems to play more of a "think tank" advocacy role in commenting on government policies and initiatives that would stand in the way of the rollout of these HTPs (from the report):

    There is overwhelming evidence that tobacco tax increases
    are effective in reducing tobacco use (232), including evidence
    that it is the only intervention proven to reduce inequalities in
    smoking (233, 234). Despite this, on World No Tobacco Day in
    2019, Marewa Glover, head of the [FSFW]’s “Centre of Research Excellence” in New Zealand, spoke out against increases
    in tobacco excise. In line with the tobacco industry argument
    that higher tobacco taxation is regressive (235), she claimed
    that such measures would disproportionately affect Māori
    populations (236). In August 2019, Glover also argued against
    the proposed ban on smoking in cars in New Zealand, saying (to
    much derision)(237) that “scientific studies have not proven that
    exposure to cigarette smoke in the car causes disease” (238).

Luckily, seems like they've already been rejected by most governmental orgs:

    In September 2017, the month of the Foundation’s inception, WHO released a statement saying that “WHO will not
    partner with the Foundation. Governments should not partner with the Foundation and the public health community
    should follow this lead” (267).
    In 2019, hundreds of global public health experts also called for governments and the public health community to
    reject collaboration with the Foundation (268).

More practically: do you have DoH enabled? If you're using Chrome, the answer is probably yes.

Thanks, but I understand that Zulip is technically capable of all of these things—that doesn't change the fact that it's still a very, very common frustration any time an org links to their Zulip channels. So it's clear that the additional setup required to go through Google auth review, get API tokens, test the integration, etc is just not feasible or reasonable to expect for many self-hosted admins.

> That said, we are planning to create a Zulip Cloud SSO option that would allow users in the many communities that aren't picky about authentication to use a single login for all their Zulip Cloud organizations

Would this be easy and accessible for self-hosted installs? e.g., can self-hosted installs now use Zulip Cloud auth out of the box with no further setup? Maybe even have it enabled by default for open organizations? That seems to be the biggest problem with the existing social login schemes. Defaults matter a lot, and if Zulip continues to ship with "Slack-like" defaults instead of "Discord-like" defaults, it's going to continue to be just as frustrating to see Zulip links on org websites.

> Open organizations can also set any channel to be publicly accessible without logging in, which I'd expect to be useful for something like FUTO: https://zulip.com/help/public-access-option.

Again, I understand that this capability exists, but it's very complicated for administrators to enable, and requires an explicit opt in for EVERY individual channel that is made public in this way, which means in practice it's very rare.

Having a good web-public organization requires a long list of steps:

1. manually editing the server config files to enable the feature.

2. having an administrator enable the option for the org.

3. having individual users remember to set channels as web-public every time they create them.

4. having an administrator audit popular channels and make sure they're set to web-public if necessary

I think many organizations would be better served with a "public channels are web-public by default" option that does NOT require editing config files or manually changing settings for every individual channel.

The distinction between "this channel is public and anybody can sign up for an account to read it" and "this channel is public and anybody can read it" is very, very slight and while I can see the value of making that distinction on an org level, I do not expect 95% of open-source orgs to have the policies / guidance necessary to enable users to confidently make a fine-grained distinction on a channel by channel level. This means that the distinction between public and web-public adds a lot of cognitive overhead and basically leads users to choose between those privacy types at random, unless their org has a "all channels must be web-public" or similar policy (like rust-lang does). In fact, checking the docs now, it looks like normal users can't even create web-public channels, so other orgs can't even replicate rust's policy without restricting who is allowed to create channels.

Unfortunately, both of these features fall prey to very common open source UX traps—having a bad out of the box experience (no SSO) ruin a user's first impression of your project, and having too many customization options, leading to user confusion on which settings to use when.

Kind of a side note, but why does every Zulip chat require a different email/password? Especially to even see the chatroom? It's really frustrating for every Zulip chat I've tried to join. We wouldn't even need server-to-server federation to fix this, even simply using a Google login would go a long way to help make these chats more accessible.

The idea is that the private key is stored outside of your configuration directory (e.g. in your OS's keychain), so your dotenv file can contain encrypted key values without leaking the value itself.