Lifter

joined 2 years ago
[–] [email protected] 6 points 1 week ago (1 children)

Yes but it wouldn't be funny if they just said "Heh, elevendon". It need a delivery sandwich. Maybe there's a funnier sandwich though.

[–] [email protected] 10 points 1 week ago (1 children)

I prefer quotes to be as close to the original as possible. Hurtful as it is. That's kind of the point here.

Censoring the bad shit that happened before is a sure way to repeat it. See holocaust denial for the extreme. Don't deny talking about the past just because it hurts.

[–] [email protected] 11 points 1 week ago (1 children)

The knife holder forces you to pull the knives up which simply is impossible with that shelf above

[–] [email protected] 8 points 1 week ago

It's really easy. I use SKLauncher and a dedicated server. You need to disable some player verification setting on the server but that's it.

[–] [email protected] 1 points 2 weeks ago (1 children)

They are not the same, but 0 can be implicitly converted to false.

What do you get if you do: 0 === false

[–] [email protected] 1 points 2 weeks ago

I agree. If anything it should check if there is a nuumber and 0 is clearly a number.

[–] [email protected] 14 points 2 weeks ago

No but then the argument above falls flat, doesn't it?

[–] [email protected] 0 points 2 weeks ago (1 children)

You are obviously not interested in listening to a word I'm saying. Goodbye.

[–] [email protected] 1 points 2 weeks ago

Perro salsiccia!

[–] [email protected] 1 points 2 weeks ago

Sticky cooks

[–] [email protected] 0 points 2 weeks ago (3 children)

Alternatively, we need to stop saying E2EE is safe at all, for any type of data, because or the arbitrary usage.

[–] [email protected] 0 points 2 weeks ago (5 children)

You probably didn't understand me. I'm saying that a company can just arbitrarily decide (like you did) that the server is the "end" recipient (which I disagree with). That can be done for chat messages too.

You send the message "E2EE" to the server, to be stored there (like a file, unencrypted), so that the recipient(s) can - sometime in the future - fetch the message, which would be encrypted again, only during transport. This fully fits your definition for the cloud storage example.

By changing the recipient "end", we can arbitrarily decode the message then.

I would argue that the cloud provider is not the recipient of files uploaded there. In the same way a chat message meant for someone else is not meant for the server to read, even if it happens to be stored there.

view more: ‹ prev next ›