Hacker News new | past | comments | ask | show | jobs | submit | erdii's comments login

In this specific case complaining about "politics" gets the sour by-taste of enabling (or at least not condoning) harrasment to the point of single folks taking their own lifes over it.

Why?! Even if you're not sure what to think about the queer movement; even if you have already made up your mind about the queer movement and oppose their ideas or some of them; I refuse to believe that any single person would not want to stop someone from bullying someone else into their own suicide!

hastily jotted rant for the folks who'd like to complain about "politics" from creeping into every discussion everywhere:

It's really sad to see so many folks disconnecting and immediately dismissing whole groups of other folks as soon as they start complaining about an issue they have because of "politics". :(

I get that you don't want to get involved in shit flinging shows and that its tedious to figure out who's in the right and who's in the wrong. Especially because there are never clear answers. If you feel like this and then proceed to complain about 'politics' creeping everywhere, please beware of this:

Pretending to be apolitical doesn't work most of the time, as politics is basically another word for "acting (or deliberately not-acting) in some kind of public sphere" which you all do, and when the "policitics" have arrived at a topic, then they'll stay there at least in that specific case you are witnessing! You just are part of a hyperconnected and confusing world with a lot of conflict, wether you like it or not.

Pretending to be apolitical also serves the upholding of whatever status quo is currently in place because anything that has even a slight chance of changing anything is inherently a political topic.

Please don't turn your heads on "political" topics or, at least, don't complain about it in that way as it mostly enables unjust behaviour to continue. It doesn't even matter if it's the person who brought up the "political" stuff who is acting unjust or the folks they're complaining about). In both cases it's probably better to either avoid commenting at all or to convey your critical thoughts to that "political" conversation.


> I refuse to believe that any single person would not want to stop someone from bullying someone else into their own suicide!

There are plenty of people who do want the freedom to say exactly what they choose, including a lengthy period of directed harassment, and shrug their shoulders if someone commits suicide over it. There's not much that can be done other than ban them from civilized spaces.


"Bullying" is a judgement. Intrinsic to the word is a judgement that what is being done is bad, and the person doing it would not describe it that way.

And by that I don't mean that it's not bad to bully people (it's rather tautological), I mean that talk of bullying often begs the question, and is intentionally done in order to elide past the actual events that occurred. Lèse majesté laws against talking about the King, elected officials, or even cops or bureaucrats now get justified as anti-bullying.

I missed any rant about politics in the blog however. But this thread has a smell of "my politics aren't political because they are true, and your politics are political because they are lies."


What the referer-replacement page was talking is Kiwi Farms, which is doing the kind of stuff that even the US First Amendment's very expansive protections fails to protect. (The criminal liability here is "intentional inflection of emotional distress", although note that most lawsuits that allege that are groundless lawsuits that largely fail to make it pass the motion to dismiss for failure to state a claim stage as "they made me feel bad" isn't sufficient to allege an IIED).


> The criminal liability here is "intentional inflection of emotional distress",

Intentional infliction of emotional distress is a tort, not criminal.


I mean this is correct. Bullies, or at least the adult ones, don’t call what they do bullying (except the absolute geniuses that think “actually bullying has a social corrective behavior, I’m just helping actually”).

We’re all just busting each other’s balls, right? Look at George, he’s laughing! He’s totally in on the joke and not at all just showing submissive deference in order to not lose face.


I'm glad at least some other people on this horrible site feel this way.


To me, you have to distinguish between harassment directed at a person, and on the other hand discussion about a person.

It is not possible to use hacker news to send messages to someones email. It is not even possible to send a dm to another hacker news user. You could potentially imagine hacker news being used to organize harassment of someone, but I have never seen either accusations or evidence of such a thing.

So then we have established, that since harassment directed at them is impossible, the issue they have is that people on hacker news write bad things about them.

Next, those things seem to often be flagged or downvoted, reducing exposure. But that is apparently not enough, because they can be found on google. So here we arrive at the core issue. There is content on Google about this person, that they would rather not be on Google. This is the complaint. So this person is basically saying that if there is unfavorable coverage of them findable on google, that is harassment, and it needs to go. If it isn't purged it's bullying that could lead to suicide.

This is a very ambitious "landgrab" if you will, and it starts to seriously infringe on other peoples rights.

It's similar in that manner to other things like "stop terrorism" or "think of the children". Yes clearly harassment is bad, and terrorism is bad, and pedophiles are no good. But we can't completely give up on our freedoms because of that.


If you want go, there is a magic-wormhole implementation called wormhole-william [1].

Rymdport [2] is a decent cross-platform app using it.

[1] https://github.com/psanford/wormhole-william [2] https://github.com/Jacalz/rymdport


Jessica Benjamin and her book "The Bonds of Love" really struck a chord with me. I believe that her concept "gender polarity" fundamentally underlies old and modern "gender wars".

Other books and authors I found really interesting:

- Estela Welldon and her Book "Mother, Madonna, Whore"

- Sándor Ferenczi, who was a close associate of Freud and pioneered the concept of "Identification with the Aggressor", which seems to be the driving force behind what we call "transgenerational inheritance" of trauma. His concept of the "confusion of tongues" between child and pathological adult is also very interesting!

- Mathias Hirsch, a german psychoanalyst who wrote a lot about trauma, love, sexual abuse and was not afraid to explore stigmatized topics. For example:

  - the effects of sexual relations between analysts and their patients (he saw parallels to incestous abuse in a parent-child relationship)
  - sexually abusive mothers and the idealization of motherhood
  - the fact that his pyschoanalyst Günther Ammon, who later became his boss at the Deutsche Akademie für Psychoanalyse, controlled the academy in a cult-like fashion


You mean something like AdNauseam?

https://adnauseam.io/

Edit: it's an adblocker that is supposed to click on EVERY ad that it blocks.


What GP describes would be stronger than AdNauseum. Instead of sending clicks indiscriminately for every ad, you would send clicks for high quality content.


That'd just end up costing the high quality content providers money. Ads wouldn't just get cheaper for them.

On the contrary, clicking only on trash, and having the high quality content have a much higher signal-to-noise ratio would have the desired effect.

Maybe.


The idea is not so much of clicking on high quality content ads, but sending visits to high quality content pages and click on the ads of those pages, to get them more money. Would obviously stop working if the sales after the ad click are not made.

But, hey this isn't a gameplan, this was just a "what if" :D


That could work, or indeed it could get them dropped quicker because they have a high fraud rate :)

I'm fully on board with the AdNauseam model which fucks about indiscriminately. The ad industry can burn.


Cannot agree more. Since the the advertisers have that much to spend, let's make them to spend more for nothing. Also by doing so, it will literally put enough noise into the data those trackers collect and renders the user profiling useless and effectively protecting us from being tracked.

If we only click ads on high quality contents, those content owner might benefit from it in short term but in long run it most likely going to back fire and make them penalized as for sure there is going to be counter measures. If we simply click every ad indiscriminately, there is no way to tell or they have to penalize everyone which almost equals to do nothing.


> to get them more money

Wouldn’t they just lose money? Ad clicks are not valuable to the businesses themselves. Only to the ad companies.


>That'd just end up costing the high quality content providers money.

I always click on Taboola bitcoin scam links for that exact reason. It's like scambaiting an algorithm.


Pretty much all pay per click ads are trash… and I guess most other ads too. No complicated logic needed here!


Plus, low quality content providers would have a high click-through ratio but very low conversion rate.

Might be interesting.


Last time I checked you could configured click frequency in AdNauseum.


I think it wouldn't be about the ads, but the visit tracking. Like, block GA from seeing your visits on trash sites, but allow when it's a high quality post/content/source, so we skew the numbers for high quality content


That's actually very interesting.

Is there any extension that blocks analytics selectively?


AFAIK, no. You would need to manually add exceptions by domain


Maybe that's where all the invalid clicks came from last year...


Lathes are kind'a more rigidly built though and I think that is what GP tries to point out.


Since no-one else posted it: The Five Dirty Words of CI - J. Paul Reed - https://www.youtube.com/watch?v=ZXXaCCbpNYw


Hey @dochtmann :)

Isn't rustls [1] also built on very unsafe groundwork? Namely ring [2], which, according to github, contains 47.3% Assembly and some C as well.

I'm not trolling here - we were discussing this a lot in my peer group lately.

[1] https://github.com/ctz/rustls [2] https://github.com/briansmith/ring


One thing to keep in mind is that the low level building blocks of crypto algorithms can be relatively easy to test, compared to higher level protocol and application code. For example, a block cipher takes simple inputs, usually a couple of fixed-length arrays and maybe some integer flags. There might be a ton of assembly under the covers, but that assembly isn't responsible for reasoning about pointer lifetimes or parsing data formats or any of the usual things that tend to trip up unsafe code. (Like a TLS implementation!) Instead, the block cipher is a pure mathematical function of those inputs, and that makes it relatively easy to come up with a set of test vectors that cover the function. This also means that the C code and Rust code for the same block cipher tend to look very similar.

Now there definitely are some tricky requirements in crypto code that application code doesn't need to deal with, like constant-time requirements. But auditing for those isn't really any harder in assembly or C than it is in Rust. In the end, porting these sorts of core crypto algorithms from C to Rust tends to be more interesting from a build systems and tooling perspective than from a correctness perspective.


The goal of the ring project is to be much safer than OpenSSL without any notable decrease in performance. That is, my goal is to give you memory safety "for free" if you switch from OpenSSL/BoringSSL to ring. In some cases it is better than free because we end up being faster.

The assembly code in ring is some of the most heavily-tested code in the world. It's fuzzed pretty much continuously in various projects that use it, and a bunch of testing has been done on it. It is from BoringSSL, and much of it is shared with OpenSSL and/or Linux kernel. As we are able to replace the assembly code with safer code, we'll continue to do so, just like we've replaced most of the C code with which we started.


thank you for your work in this. we've been using rust-tls/ ring for some time now in our product.


It uses ring for cryptographic operations, yes. However, note that all the ASM in ring is meticulously kept up to date with BoringSSL upstream, which ring was derived from. Plus, there was pretty successful third-party security audit last year.

Also, the goal is definitely to bring all of that code into Rust, unfortunately Rust lacked the features to do that safely (things like const generics).


Could I ask why const generics would be a blocker? I see how it would help facilitate more elegant APIs as well as better stack allocated structures. However is it not possible to live without this, possibly with a slightly more clumsy design?


>Plus, there was pretty successful third-party security audit last year.

The security audit referenced by the post suggests offering EverCrypt as an optional alternative to ring. Are you going to act on the audit's recommendation, or continue to only offer ring?


> Isn't rustls [1] also built on very unsafe groundwork?

Depending on what you mean by "groundwork" literally everything is. Hardware doesn't obey Rust's rules, and you need to interface with hardware to get input, and do output, so literally every program will have unsafe code at the base.

The key difference is that Rust gives you the tools to explicitly demarcate what is safe, and what is not, and build safe abstractions on top of (hopefully validated) unsafe foundations.


> Hardware doesn't obey Rust's rules

Neither does the OS where rustls is running.

I think Rust will have more adoption and more libraries like Rustls will be developed. I also think that when this happens, also more exploits targeting Rust code will exist too. I guess the excuse (sorry for using this word) will be: "In fact, the Rust code is still safe. What happened is that a pointer returned by (or used in) an underlying C library got messed up with a very clever timing attack, and somehow the pointer emerged into Rust code... etc.".


Also, ring enforces everyone to use the latest version by pruning older versions from crates.io, which means your builds will fail every time they update.

Main reason I stopped using it.


Of course, if our claim is that we want to avoid security bugs, and we accept the principle that (without some more specific definition) all bugs are security bugs, then any time ring fixes a bug we want to avoid using the old version...

Now for all I know, ring has never fixed any bugs and it just loves adding new API features so that this pruning has no desirable security properties at all, but in principle I can see that this is the equivalent of the standard boilerplate Linux release text which tells you that you should update to the latest kernel because they fixed bugs.

If you have a complete threat model and if you are capable of the insight needed to examine all changes and determine how they impact that model, you could successfully choose whether to upgrade based on whether a new version fixes a bug you care about. But chances are you don't have such a model and even if you did you aren't capable of the inhuman levels of insight needed, even in a language like Rust (and forgetting that we're talking about this because large parts of ring aren't even in Rust).


crates.io and the Rust community adheres to semantic versioning.

If ring wants to notify me that I should update, they should send an email to a security mailing list, open a CVE, register the cve in any of the rust services to notify users with those dependencies (there are some, like crev), etc.

Pruning your releases from crates.io just means that I am going to be annoyed the first time it happens, will start looking for a solution the second time it happens, and it won't happen a third time (and it didn't). If you want to wake me up a Saturday at 4 am, the world better be on fire.

This is probably the only dependency I can remember as being... more than annoying, toxic. I still prevent any of my dependencies from ending up with ring as a dependency. If that shows up in our dependency tree, CI fails, and that change cannot be committed. Unfortunately, this pruning of old releases was only one of the issues with ring (there were others, like cross-compiling it wasn't easy, etc.). All in all it was a no brainer to drop it as a dependency.

I don't think I've ever met a rust dev with something nice to say about `ring`. In a meetup a couple of years ago another rustacean said: "`ring` is so secure that it protects you from using it in your projects". Sums it pretty well.

The library has couple of thousands of daily downloads so for the latest version, and like 25k daily downloads for other versions, so maybe things changed now.


When I merged security fixes from BoringSSL/OpenSSL, I yanked the old versions of ring that didn't have the security fixes. I thought that was a pretty reasonable policy, however people who like to comment in these forums disagreed very loudly, so I stopped doing that. Not sure that's better, but there's less complaining.

In general, my initial thinking was based too much on the assumption that people would help maintain the things that depend on ring to update them to the latest release. It turns out there's less cooperative maintenance like that than I expected.


I loved your policy and appreciated how principled it was. People here are too harsh and most of them don't write code in Rust where regular updates are much more the norm than other communities.


Yanking releases which have bugs / vulnerabilities in them is very much not the norm in the Rust community.

This is why projects like https://github.com/RustSec exist.


I don't know about that, crates that RustSec has advisories for are often yanked, in my experience.

Bugs? No. Security bugs? Yes.



Sure, it's quite possible that not every single one ever is. One single version of one single library not being yanked doesn't mean that nobody ever does it.


> In general, my initial thinking was based too much on the assumption that people would help maintain the things that depend on ring to update them to the latest release. It turns out there's less cooperative maintenance like that than I expected.

I think that's a reasonable assumption.

What isn't reasonable is to expect people to "upgrade right now". Not everybody lives in your time zone, so when you yank a dependency, you might be breaking a workflow in the other part of the world at 3 am, and if some webserver doesn't deploy or whatever, somebody will get a call.

I'm not suggesting this is an easy problem to solve, but there is a wide range of options before "never upgrading" and "force an upgrade right now". Some of these are supported by Cargo via Cargo.lock, etc. so the responsibility for how this is handled doesn't fall on one library or person.

Building a secure system is also not the exclusive responsibility of `ring`. If I'm building a secure system, I have to assume that `ring` will have a bug that's exploitable at some point, and that someone will use it in a zero-day, and my system needs to be secure even if that happens.

So "updating right now" doesn't buy me much. Its something that can wait until after a meeting, or after my vacation, or until monday. Its not a "the world is on fire" situation, even though it would still be pretty severe.

I'd still like to get "notified" ASAP and asynchronously somehow. While updating ring is low effort, the update still needs to "internal QA,..." etc. at companies, and that takes people's time that must be planned on.


In a properly-designed CI/CD system, a dependency getting yanked isn't an emergency unless you choose to treat it as such. In particular, if you don't want your build to fail because some dependency got yanked then you need to use a Cargo.lock, and you need to ensure that you're not overzealous in your use of cargo-deny and similar tools.

I'm not sure if you were affected by this, but Cargo introduced a (regression) bug a couple years ago that caused it to fail when a crate got yanked when it shouldn't have. This bug was eventually fixed, but lots of people blamed ring for this bug. If this Cargo bug hadn't been introduced then most people who were using Cargo correctly wouldn't have been negatively affected by ring's old policy.


With software which needs security considerations it's also common to want to test the vulnerable versions, write tests internally and verify the broken/fixed behaviour. Yanking old versions makes this annoying. (Yes you can rebuild from the repo tag, but that's annoying, especially in indirect dependencies)


> If you want to wake me up a Saturday at 4 am, the world better be on fire.

In a previous role I actually have had things set so that I might be woken at 4am on a Saturday, IIRC specifically under certain conditions it'd play "Straight out of Compton" at full volume on my Hi Fi to ensure my attention, which gave me about 10 seconds before it gets real loud.

I was leak hunting, specifically looking for a huge leak in a production system that we couldn't reproduce on smaller test systems - so I needed to wake up, attempt to diagnose the leak and then (regardless of whether successful or not) mitigate it (kill the bloated process, one transaction fails but everything else will auto-repair) and go back to bed.

But what I don't understand here is, why are you constantly rebuilding and alerting on failure? A CI flag can wait until Monday stand-up, are you auto-deploying any change of state even when there aren't any humans around to cause that? Why? That strikes me as up there with Apache's "But your Good OCSP response expires in 18 hours, so I stapled this newer Bad one instead" in terms of terrible mistakes.

If instead your new builds fail after pruning, the human who is causing a new build can decide what to do about that when it happens, no need for anybody to be woken at 4am.


Your Saturday 4am may be someone else's Friday 3pm. Humans may be around and doing their normal work.


Which is why you don't[1] push to production on Friday at 3pm.

[1] As always there are exceptions to this rule


That's not a great rule in this case. Unless you also don't push on Monday 1pm because it could be someone's Monday 1am?


I looks like we are talking about different things.

So you have a team (i suppose could be just 1) or teams across few time zones.

Each team should deploy in a way that they have people ready to fix thing if they go bad.

You can do that by having large enough team in similar timezomes (+/- 2-3 hr), or by paying extra for having people on standby at 1am.

My personal opinion is that having large enough team (again could just be 1 guy) in similar time zone is preferable.

Bottom line is, deploying new stuff is always risky. That's why people spend so much time trying to reduce this risk (various test, CI, staged rollout ...). And sometimes all of that still fails, and you need people to either rollback or fix it on the spot.


I thought crates.io doesn't allow removal?

You can yank crate versions, but that doesn't affect builds which lock a version via cargo.lock so failing builds shouldn't be an issue.


They meant yanking.


That hasn't been the case for a long time, a year or more.


Your builds will only fail if you don't check in your lockfile.


That issue should be fixed in the next release. It is definitely a nuisance, but fixing it is not easy due to the assembly code involved.


Had the same thought the other day: https://cryptologie.net/article/520/cryptography-and-assembl...

Not a fan of assembly for cryptographic code.


Wait... Naive question: shouldn't you, especially in this case, still nag the account owner about his own unverified sessions? What if a bad-actor homeserver slides in a new session to snoop around?

BTW: I absolutely love the cross-signing move and riot/matrix in general! :) Thanks for your great work on this!


We do nag, in that all the green shields will suddenly go bright red. But we don't block the user from being able to send messages until they've resolved the problem.

It's possible we'll reintroduce this once cross-signing has been fully adopted though; it's tricky because we need to distinguish between encrypted rooms where you simply don't care if random users have unverified slides... versus ones where it's a disaster if an unverified session slides in. Finding the right UX for that is tough, but we think the current balance is an improvement.


Alrighty, thanks for your answer :)

That is really a tough UX problem... Maybe a room could have a "sensitive content" flag that is enabled by default for one-on-one chats and can be manually enabled for group chats.


AFAIK as more and more chats become encrypted (as it is the default for private rooms) then a rogue server operator wont to be able to snoop because they can't decrypt the messages unless you go through the verification process. And this aside, there are are few unobtrusive, but noticeable icons letting you know that you have an unverified session.


Since 8 hours now...

Does anyone run their own image cache/proxy and is now happy that they are not affected by this issue? If so: what solution are you using?



That doesn't solve the general problem of complying with legal orders.

For example, how would escrow help with wage garnishment, suing a company and winning, or generally forced transactions by court order?


Not who you are replying to, but I answered and addressed those claims in a sister comment, here:

https://news.ycombinator.com/item?id=23199291


You keep saying you answered but you have not. That is very unclear and just throwing around words.

You haven't understood the idea and instead hang on to narrow focus around cash, which had nothing to do with the argument, because most people have digital money that goes through institutions. Using fringe cases to justify the common is the wrong way around.


If your argument against cryptocurrency could also apply to cash, why don’t you also say so? My point is that cryptocurrency has aspects of digital assets and cash assets simultaneously. So if your argument equally would apply to cash, which is commonly used, then I think it’s worth pointing that out.

Also, I don’t agree that my writing is unclear. I find your dismissal unjustified by your arguments. I simply bring up a counter-example to your argument with cash. You saying it is fringe and beside the point is not an argument. To then criticize my writing is to miss the point I was making. I don’t find that you are debating in good faith when you make personal attacks on quality of writing when your own argument hasn’t been made or won.


You haven't clearly replied to the scenario I presented and have rather used this cash analogy (and idea that if I don't address cash than the question is invalid) to continually deflect from from having to answer the original question and how it applies to cryptocurrency.

Cash is a bad analogy because it is the only widely used currency, it defines what we mean by currency, and it has always been a part of modern history in some form. Cryptocurrency has fundamental differences from a digital, public, immutable ledger.

So if you'd like to get back to the original questions, I'd be happy to continue this discussion.

However if your only defense for cryptocurrency is "cash does it too so we don't have to talk about it" then we can stop here.


I’m not advocating for or defending cryptocurrency. I’m asking questions to clarify what it is you are asking. I don’t see why you think I am deflecting. Asking questions is as old as the Socratic method.

If you don’t think analogies to cash are a good answer to your questions, please restate your question. I’m not using cash as an analogy, I’m using it as a counter-example in the monetary marketplace that proves that different monetary instruments have different properties, some of which are inherent to the medium of exchange. I want to know why you think cash isn’t a good answer to your questions. I also am curious why you think cryptocurrency is a bad answer to your questions, if indeed you do.


as expected...

I asked a question about how an immutable ledger, with public consensus, deals with the reversal transactions as ordered by the rule of law. Do you have an answer for that?


The deadline for YC's W25 batch is 8pm PT tonight. Go for it!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: