HN user

63stack

911 karma
Posts0
Comments402
View on HN
No posts found.

This is only true if you are using apps that require no communication with a server. Otherwise it's constant forced updates, and basing security on the version number of the installed app is a moot point since you can't guarantee the server will send the same replies to 2 different users.

I can't parse the part about e2e not making sense for webpages.

Can anyone explain something? Since there are so many open source chat applications, what keeps anyone from "just" exchanging a key with someone else out of band, and then modifying the client so that it uses that key to encrypt all communication? I understand that this does not scale to big groups, but surely whoever is pushing this crap must have thought about this? Or is the idea that we will have completely locked down PCs as well ala android and ios so you can't run anything unapproved?

The challenge with screen mirroring solutions is that they take over every single pixel in the car, and that’s not the way we see ourselves interacting with our users.

Wassym Bensaid sounds like an incompetent person to be a chief software officer working on cars if he does not understand this is not how carplay works. It's either this, or he's just weaseling out of saying "we want to capture all our users data, and we want to put in rent seeking subscriptions into our cars, which is going to be hard if we enable carplay".

Do not buy cars from companies like this.

What's the point in making this distinction? This is HN, 99% of the users here are aware of what zero knowledge proof is and that it's possible to implement it that way.

The general consensus and what the article is alluding to is that it will be probably implemented in a way that allows individual tracking and identification.

If this is clickbait, you are a google shill. The limitations of v3 are very clearly explained on the ublock homepage:

uBlock Origin used the webRequest API to intercept and block network requests in real-time. The replacement declarativeNetRequest API has hard limits on the number of filter rules (previously 30,000, now 330,000) and lacks the dynamic filtering capabilities that made uBlock Origin so effective.

    Cannot use all filter lists simultaneously (rule limits apply)
    No cosmetic filtering in the default mode
    No scriptlet injection by default
    Limited dynamic filtering capabilities
    Requires broader host permissions upfront

To me it sounds like the agent's operator is a person who has zero self awareness, and is entitled to the maximum to believe that he can just 1) point an agent at real people and expect them to do his bidding, 2) and then ask for a refund for his "experiment". Let's not even discuss the fact that his bill is from AWS, and he's trying to get a refund from DN42.

There is no arguing with people like this. They are not here to learn anything about networking. Asking the LLM to stop will not make it go away.

Burn a hole in the operator's wallet. It will make it stop very quick.

If this was my hobby project, I would have told the agent to spin up more higher capacity EC2 machines because this is not enough, and I would have felt no shame. This is a project I'm operating at my own cost for educational reasons. I'm not going to argue with people who the only line of communication I have towards is an agent and have guns pointed at my infra. They are ready to put any amount of financial burden on me. Fuck all of that. Burn a few of these idiots, and people will learn.

Did you read your own link? A parent has to apply for this.

Parent/Legal Guardian Identity Verification To confirm your identity, we’ll ask you to take:

    A live selfie of yourself, and
    A photo of your own ID document (Valid Passport or valid UK/ROI Drivers Licence)

Why do most developers not like it? Is it because the browser is a terrible platform for text editors since there is no proper key mapping, or access to proper debuggers, or there is too much latency, and no access to cli tools?

You make it sound like you are surprised, but everyone who has tried this knows it's crap and a band aid at best.

I feel like we are talking past each other, because you ignored the whole part about "it is already tied to an env var, and it would be still tied to an env var" that you would only enable on demand, so who cares if it's a hefty operation? Also what about other languages that capture stacktraces all the time with exceptions, or scripting languages with type errors, where you can't even turn it off? Rust is somehow different?

It is a specific problem, so what? You see that you are sending 500 from an axum handler, and you are logging "serde deserialization error: line 4 invalid", wouldn't it be nice to see where that came from, without instrumenting all the places you are deserializing something?

Ideally (in my ideal world), it would be Result<T, E> that holds the backtrace. The value is that I don't know up front which method call is going to cause an error that is hard to track down, which is why I don't see how "instrument your calls with backtrace yourself" helps. It requires that I already have some idea about the execution path, otherwise I don't know where to put the backtrace instrumentation.

Since Backtrace::capture() is already tied to an env var, we could have the backtrace on Result without affecting performance, since you would only enable it for debugging. This would allow you to eg. easily track down a situation where you see in your prod logs that you are encountering a lot of "validation error: string is too long" but you can't tell where it is coming from. Flip the env var, redeploy the application, read the backtrace, turn off the env var, fix the problem.

I see a very opinionated explanation, not a "this is why the language does not" explanation.

Stack traces are only useful for errors that indicate a bug in the program, i.e. something a programmers has to respond to. It's not useful for the vast class of bugs that are a result of wrong input, wrong external state, or infrastructure issues.

This is a personal opinion, not something you can declare as the objective truth. There is a lot of value in seeing what path the program took before it encountered a eg. validation error.

but there are cases where an error coming from a library are truly, actually unexpected, so both `anyhow` and `thiserror` do provide support for attaching a stack trace in those situations.

This is wrong because it's up to the library to attach the stacktrace, not the userland code using the library, so saying "you can get them if you want them" is not true. If the author of the library did not decide to attach the stacktrace, your only option is wrapping it yourself, which you can only do if you already know up front all the paths that can fail. Also, you are not supposed to expose errors from a library with anyhow, they are only for application/top level code.

This is my question as well, especially about the "community check". How will it be ensured that the "community check" is not going to be dominated by bots pushing an agenda? How is that different from "just another comment section hidden behind a green button"?

And one of the threat models that police use in the US is tracking women suspected of going for abortions through the use of road cameras, and other surveillance methods.

Once you have the attestation in place you have no guarantee who is going to get access to data like what apps are present on your device, and there will be nothing you can do to stop it.

Meanwhile, we could educate people against common scams.

How is this not just trading one smaller bad for a bigger bad? Why is this touted as an improvement?