dagenix

Why?

Could you please explain what I'm inventing?

What if you are filming and standing still and then the police officer walks toward you?

> I don't know what ANGLE is, but WebGL is based on OpenGL. As this article says "WebGL’s API is really just OpenGL ES 2.0"

I believe that ANGLE is a library that is widely used to implement WebGL by translating OpenGL ES calls into Direct 3D calls: https://en.wikipedia.org/wiki/ANGLE_(software)

In my experience, running X11 over a network worked very poorly.

There is significant overlap between former X11 developers and Wayland developers. They didn't drop it because they are incompetent which seems to be what your are implying. The people that decided to drop it are probably the people that know X11 the best.

HTTP/2 was based on SPDY which was created by Google. HTTP/2, however, is an IETF standard. The IETF is not an advertising company. The claim that HTTP/2 was introduced by an advertising company is false.

The claim that HTTP/2 is a commercial technology is unsupported.

HTTP/1.1 pipelining is flawed. The problem is that if you pipeline requests for A, B, and C, the responses need to come back for A, B, and C in that order. The server can choose to either process pipelined requests serially or in parallel at its option. If the server chooses to process the requests serially it more or less defeats the purpose of pipelining. If the server processes the requests in parallel, it has a problem: let's say that A is a slow request and that B and C are fast requests generate a large amount of data - the server has to wait for A to complete before it can respond with B or C but in the meantime it has to store the responses for B and C somewhere. This is a great way to DOS a server: pipeline a bunch of slow requests followed by large ones and see if the server runs out of memory or disk space.

Servers don't support pipelining because it can cause a DOS. Clients don't support pipeline because servers don't and also because the head of line blocking caused by a slow response means that they will often get better results by opening up more connections than to try to pipeline things.

There isn't a conspiracy. Pipelining just isn't a good technology.

IPv4 subnetting and IPv6 subnetting don't really work the same way, though. With IPv4, there are (almost?) no ISPs that are handing out class A blocks to consumers. The vast majority of consumers will get a single IP address - and then they have to use a NAT setup to create subnets on their end.

IPv6 is _dramatically_ different. Its actually possible to get a /48 or a /56 - sometimes just for free as part of general operations. That leaves 8 or 16 bits for the customer to create hundreds or thousands of subnets. Unlike with IPv4 where most customers don't get more than one IP address, you don't have to use a NAT setup if you have a /48 or a /56. Even if you only get a /64, that still leaves 64 bits to give every device its own globally routable address without having to setup NAT.

Do we need 64 bits to identify individual devices in a subnet? IDK, maybe not. but if you are doing an apples-to-apples comparison, with IPv4 you have 32 bits for global routing. With IPv6 you have somewhere between 48 and 64 bits. The remaining 64-80 bits of the IPv6 address don't have a good analog in IPv4. So, in a lot of ways, IPv6 is a lot like taking IPv4 and expanding it to something between 48 and 64 bits and then the remaining bits you can think of basically almost like extra fields to encode information that IPv4 doesn't support.

In practice, ipv6 often uses only 48-56 bits for global routing with 8-16 bits usable for subnet ids or routing within a customer site. The last 64 bits of the address are used to identify a particular device in a subnet. So, an ipv6 address is a lot bigger than an ipv4 address - but that is because those bits are doing more things than they are in ipv4.

> with a user-controlled local browser setting and a new type of permission request popup.

Settings and pop ups mean that users have to understand them - which can be a huge user education challenge. I'm pretty skeptical of the argument that it's simple to add in a new user facing pop up and have the majority of users use it correctly.

I agree with the person I'm responding to 100% on the technical merits.

> everybody involved should be ashamed of themselves

Have you ever read about how open source project leaders often experience a lot of toxicity and anxiety about trying to keep up with the users they are supporting for free? If not, I suggest you do since this is the exact type of comment that is hurtful and unhelpful.

> you absolutely deserve to be labelled immature and even childish

Do you appreciate that people aren't making technical mistakes on purpose just to spite you? Or that maybe some of the folks writing these libraries are experts in fields other than dependency management? Are you an expert in all things? Would you find it helpful if someone identifies one thing that you aren't great at and then calls you names on the internet over that one thing?

There is a pretty significant difference between making a technical critique and just being rude. And being right about the former doesn't make the latter ok.

There is a lot that can be improved with python packaging, but calling it "childish" is itself a pretty immature comment.

The comment you are responding to did a great job of explaining the situation. I don't know what you are trying to say.

You don't agree with it's security tradeoffs. That's fine. But it doesn't make it "lousy".

I don't know anything about this Brazilian Gail company, but I hope nobody uses them.

> Git didn't _need_ to switch to SHA1DC, but they did because the cost was minimal and it's still a good idea to defend against known attacks.

I'm confused with how a SHA1 collision being found is an "attack" if git truly doesn't care about collision resistance.

> This is a general problem with binary files: they're hard to properly review. Having unreviewable files in a repository (binaries, machine-generated configs, etc.) is already a security problem; hash collisions would just be one (very difficult) way of exploiting that problem.

I don't think you can ignore the use case - people do check binaries into git with the expectation that git will keep track of them.

> Git was designed for collaboration between trusted parties; collaboration between untrusted parties (e.g. pulling changes from untrusted sources) is a much harder problem that git doesn't pretend to solve.

Maybe that is how git was designed. But it's not how git is used. People do pull from repos that they don't fully trust. Maybe just to examine a change before throwing it away. What people don't expect is that by pulling from such a source that an unexpected file could get into their repository due to a collision attack. That is why git switched to SHA1DC - if git truly didn't support that use case, they wouldn't have needed to.

> Collision attacks are real, but they have yet to impact git (beyond adopting SHA1DC, I guess), despite how big of a target popular git repositories are.

I agree that collisions attacks are real but aren't a practical issue yet. What I was responding to was your comment:

> I haven't heard of any second-preimage attacks against MD5, much less SHA-1, so mlindner was correct in asserting that MD5 would be fine (assuming 128 bits are enough). See also the analysis in [1].

In that comment, it seems that you were saying that collisions attacks weren't a problem at all. But, it seems like you are saying in your more recent comment that "collision attacks are real"?

I don't believe that is accurate.

First - if git really didn't care about collision resistance, there wouldn't have been a need to switch to SHA1DC as the hash function. They switched because they care enough that they were willing to accept the performance penalty.

Second - imagine this scenario: a user creates two commits with the same hash, one with a valid change and the second with a malicious one. The collision could be created by playing around with some data in a binary file - so, this is a collision attack not 2nd pre-image. The user then submits the change to the upstream and gets it approved. The user maintains a mirror of the upstream repo into which they place the malicious commit. Anyone that pulls from this mirror will think they have the same code as the upstream, even if they compare hashes.

So don't use an untrusted mirror? I guess - but that is something that should be possible with a strong hash. And if git really didn't want you to do that, it would provide for better ways of tracking where objects were actually pulled from.

Anyway, collision attacks are real and can impact git. They just aren't as bad as a 2nd pre-image attack.

I understand if they need to update the date to get it to show up at the top of the blog. But, in that case they can just add a few words to the front of the article saying that they are republishing an item from September.

Are you planning on fixing the misleading date?

Is the complaint that he was hired or that his previous surveillance work was glorified as part of the hiring?

Your question is irrelevant. If you don't care about security, SHA1 is a bad choice because there are faster hash functions out there. If you do care about security, SHA1 is a bad choice because it has known flaws and there exist other algorithms that don't. The only valid reason to use SHA1 is if there is a historical requirement to use it that you can't reasonably change.

Any analysis about how hard it is for an attacker to get a file on your local file system via a cloned got repo, cached file, email attachment, image download, shared drive, etc is just a distraction.

Why would you pick a function that is known to have issues when there are other functions that do the same thing but don't have known issues?

Your comparison is flawed. It's more like if you have a nail and next to it a workbench with two hammers - a good hammer and a not as good hammer. This isn't a hard choice. But for reasons that are unclear to me, people in this thread are insisting on picking the less good hammer and rationalizing why for this specific nail it isn't all that much worse. Just pick the better hammer!

Why would you pick SHA1 which has significant attacks you need to consider as opposed to something like SHA2 that doesn't?

If you are choosing between a CRC and SHA1, you probably need to reconsider your understanding of the problem you are trying to solve. Those algorithms solve different use cases.

They do have your consent - thats how banks work and you agree that when you deposit money in one. It seems that you are unhappy about having to consent? But, what I'm confused about is what you are upset - your money in a bank is FDIC insured, so, unless you have account that exceed the limits of that insurance, you have no risk from you bank going insolvent. So, what's the problem?

That's a different trade off. It's not a solution.

> I think TikTok and similar products are garbage and will lower the average IQ, especially of younger generations.

I have lots of concerns about TikTok and refuse to use it myself. But this is ridiculous - and that upsets me quite a bit because is delegitimizes the actual problems with TikTok. TikTok will not lower anyone's IQ. This is straight up just old man yelling at cloud. And that does us all a disservice.

"metadata" & "everything we see" is not the same thing as "all internet traffic". I'm not trying downplay the quantity or sensitivity of what is stored, its just the idea that all internet traffic is being recorded by any government seems technically very challenging and makes me very skeptical of that unqualified claim when I see it.

Citation?