jiiam

no profile record

comments

2 lata temudiscuss

My experience with IaC output is that it's so broken to not only be unhelpful but actively harmful.

2 lata temudiscuss

EDIT: regarding the part about signal and whatsapp I must clarify that of course the possibility of inserting a backdoor on the server side is far more dangerous than the client side: Signal has verified builds so a backdoor would be evident and the user could stop using the service. And the same actually holds true for any app using E2EE if the user simply avoids autoupdating and wait for some confirmation that it is ok to update, at least as long as we can assume that any client side backdoor would be found by independent researchers.

I also want to repeat the original point that started this whole conversation: the point was how easy it would be for Telegram to access the chats and if the justice system can compel them to do so.

When people say it has the data in plaintext, I take as a "they can access them whenever the want right now without changes", and yes of course the could ultimately access the data (in fact they don't claim to be unable to). What they claim (and I believe it feasible) is that even if a judge seized all the assets and servers under his/her jurisdiction it would be impossible to decrypt any user data.

2 lata temudiscuss

I am saying that in practice the security might be structured in such a way that it requires several different parties to connive, rendering it essentially fine.

I mean, having to modify server code in order to access data that is "effectively plaintext" is not so different from installing a backdoor inside the client: it's not like the user has any choice of client, so even for apps like whatsapp and signal that run E2EE one is still making a leap of faith.

If we add the fact that everything runs inside an os built by companies who may or may not be constantly spying on their users we could say that by definition there's a lot of stuff in our lives that lives in "effective plaintext".

2 lata temudiscuss

I mean at this point they could also change the code running on the user devices, probably someone would notice but that's another story.

The point is: even if they could, should they do so when compelled by authority?

2 lata temudiscuss

This could be extremely unfeasible. For example the code could be generated by a third party and encrypted before arriving on a server controlled by telegram and sent to the user. Or it could be generated inside a nitro enclave. Sure ultimately someone could modify the server code somewhere to log the code or any other specific message before it gets encrypted, but at this point we are talking about inserting a backdoor.

2 lata temudiscuss

Something being true only by definition is unfortunately a very weak claim.

For example the company servers could be hosted on an island with armed guards instructed to burn everything if anyone approaches and the decryption happens only on those servers: sure they have access by definition, but they really don't.

2 lata temudiscuss

I think this statement requires a stronger argument, since even if they could have access to the data in theory there are concrete implementations where it could be extremely unfeasible.

For example, since we are in the realm of speculations, I propose the following alternative to the plaintext or accessible decryption keys: the decryption could happen inside a nitro enclave making it essentially impossible to access the data without changing the application code.

I'm not saying that this is what happens, just that I don't think that one can so easily deduce that "they can access the data" just from the fact that "they send you chat history to you".

2 lata temudiscuss

There is quite a large amount of people believing that Telegram stores messages in plaintext. I would like to know how they got that idea.

So far the best I've got is something along the line of: if you can get your chats when you log in with a new device, then so can a Telegram employee. With no proof of the claim of course.

2 lata temudiscuss

EDIT: I just want to clarify that I don't believe the claim that an employee can intercept the validation code

2 lata temudiscuss

Maybe? When you login from a new device you're asked to provide an OTP so maybe there is at least that layer of protection and, hopefully, requires some circumvention at the application code level.

However I think the real question is: even if that's possible, can law enforcement compel Durov or an employee to do so?

2 lata temudiscuss

Just to be clear, are you saying that his claim

> Telegram uses the MTProto 2.0 Cloud algorithm for non-secret chats[1][2].

> In fact, it uses a split-key encryption system and the servers are all stored in multiple jurisdictions. So even Telegram employees can't decrypt the chats, because you'd need to compromise all the servers at the same time.

is false? If so can you cite a source? (The claim is just a summary of the FAQ https://www.telegram.org/faq#q-do-you-process-data-requests)

2 lata temudiscuss

According to the Telegram FAQ (https://www.telegram.org/faq#q-do-you-process-data-requests) data on their servers is encrypted and the keys are split and stored in different jurisdictions (and different from the jurisdiction where the data is stored).

With such a setup what does it mean to comply with warrants? Are we saying that Telegram should voluntarily yield all information regardless of jurisdiction?

2 lata temudiscuss

> Both openvpn and wireguard protocols are trivially blocked by DPI.

I don't understand why this matters, it's not like your ISP will ever block this kind of traffic since every company that has any form of IT department uses some form of VPN making it not only a legitimate kind of traffic but also quite common.

2 lata temudiscuss

> It's the reason some people will tell you Arch Linux worked perfectly on their machine despite having plenty of problems.

I feel personally attacked

2 lata temudiscuss

I used to run a telegram webhook for myself and kept telling myself to make it in a service. You can deduce by the fact that I'm not sending you a link that it hasn't happened yet

2 lata temudiscuss

Thanks, I needed to have this thought formalized. I see now why I have a hard disk full of perfectly architured dead projects, and also why the live ones are never going to be perfect

2 lata temudiscuss

In game theoretic terms all of this looks a lot like a Nash equilibrium to me and, as such, fells inescapable

2 lata temudiscuss

Also in Haskell:

1. Start by doing everything in ReaderT Env IO

2. Learn all about mtl (or monad transformers, free monads, freer monads, algebraic effects, whatever)

3. Do everything in ReaderT Env IO

2 lata temudiscuss

> Those don't seem to be names of parameters, but rather of types. It's missing parameter names entirely.

The rest of the definition is at the end, to see it as a whole:

  splitAt :: Eq a => a -> [a] -> [[a]]

  splitAt x xs = ...

To clarify, I assumed that by using the constraint `Eq a` and the name splitAt there was no need for extra clarification in the names of the parameters but apparently I was wrong.

2 lata temudiscuss

Just to give a different pov I find Haskell very intuitive, and particularly I find that code written by other people is very easy to understand (compared to Java or TypeScript at least).

And by the way x and x' are totally fine names for a value of a very generic type (or even a very specific type depending on the circumstances), as long as the types and the functions are decently named. I mean, how else would you call the arguments of

splitAt :: Eq a => a -> [a] -> [[a]]

?

There is no need for anything more complex than

splitAt x xs = ...