Hacker Newsnew | past | comments | ask | show | jobs | submit | more vog's commentslogin

If you haven't been aware of the great work of the European NGO "noyb", this should grab your attention.

Facebook's GDPR violations are not just tolerated by the Irish DPC, they are outright protecting Facebook. Until recently, nobody was able to prove that. But noyb finally managed to annoyi the Irish DPC so much that the Irish DPC finally showed they true face by trying to force noyb into signing an NDA for documents that have clearly, and legally proven, a public interest.

These "Advent Reading" sessions are noyb's way to kick back the blanket so everyone can see what the Irish DPC is actually doing here.


If you haven't been aware of the great work of the European NGO "noyb", this should grab your attention.

Facebook's GDPR violations are not just tolerated by the Irish DPC, they are outright protecting Facebook. Until recently, nobody was able to prove that. But noyb finally managed to annoyi the Irish DPC so much that the Irish DPC finally showed they true face by trying to force noyb into signing an NDA for documents that have clearly, and legally proven, a public interest.

These "Advent Reading" sessions are noyb's way to kick back the blanket so everyone can see what the Irish DPC is actually doing here.


PostgreSQL allows for all of that: User-defined types with user-defined index structures and whatnot. PostgreSQL is great and flexible, yet transaction safe and fast. You should really try it. It is one of the highest-quality FLOSS projects I have ever seen, not just in term of code quality, but also in terms of project and community management.


Congrats for this simple and beautiful website!

I wonder how you manage your overall style, though. Is your design set in stone, do you never change it or fix quirks? If you e.g. change from GitHub to GitLab, would you edit the footer of every single page?

One small suggestion: Please advertise your RSS feed to the browser using the <link rel="alternate" ...> tag. Ideally on every page. Otherwise, visitors of your blog articles (like myself) get the wrong impression that you don't provide a feed, until they go back to the main page and scroll down to the bottom.


I used to use a lot of SymPy, but finally switched to Sage. This is Python as well, but has some syntax extensions and sensible defaults that reduce many quirks of Python. For example, you can write 1/2 instead of of Rational(1,2) and a^b instead of ab.

Moreover, Sage integrates lots of other libraries seamlessly. I remember doing lots of polynomial calculations and groebner basis stuff, and generating Singular script from Python seemed to be very elegant in the beginning. However, this quickly showed severe drawbacks. With Sage this all became easy and seamless again.


There was a post about Sage not long ago that it is used commonly among cryptographers.

As an aside, the statistical libraries and conveniences of R ("missing value" is a data type; every object is an array meaning you can call functions on arbitrary arrays) are the only reason that I still use R for some niche applications. I wonder whether pandas or something like Sage will actually take over this functionality. My impression is that the packages in R are so isolated (in a somewhat good sense) for a niche application that they are both difficult to emulate in Python and happen to keep on working long after they were written (and not necessarily maintained).


> The fact that its default chats are not end-to-end encrypted and are stored in plaintext on its servers is a concern.

"Concern"? This is a deal-breaker.

> Everyone who talks about this as a huge deficiency should also consider that this applies to email too, unless one always uses encryption (like GPG/PGP or S/MIME).

The contenders here are Signal and WhatsApp, not email.

Having better UX and safer defaults than email is nothing to be proud of - it is the bare minimum.


> "Concern"? This is a deal-breaker.

Anyone who finds themselves using email disagrees in practice. Plain text on the servers are no practical deal breaker to the vast majority of people, not even the majority of HNers.

> The contenders here are Signal and WhatsApp, not email.

This is the problem:

Stop recommending WhatsApp and we are a little closer.

Many of us can agree that Signal is probably more secure, even after the horrible bug they had in their desktop client not that long ago.

But WhatsApp is nothing but a metadata collection engine for Facebook.

I'm not too happy with the saying about not paying meaning you are the product, but in this case it fits perfectly:

1. Facebook buys WhatsApp, makes it free, promisese they can't combine it.

2. Turns out Facebook is too greedy to even pretend it wants to keep its promises, and goes on to update Terms Of Service, adding a default opt-in.

Can we stop recommending WhatsApp now?

Signal exists critical stuff.

For everything else, use something that works: Telegram, email, whatever, -even WhatsApp.


> "Concern"? This is a deal-breaker.

For me it's a concern, not a deal breaker. Whenever another app with end-to-end encryption comes close to Telegram on features, speed and UX, I'll switch to it completely. Currently Wire seems closest, but it still has quite a bit of catching up to do.


I find it quite telling that a short outage does more damage to Facebook than any data breaches and mishandling of user data.


The article is refreshing and makes clear that REST is violates KISS, making a good case for RPC with no nonsense on top of it.

I fully agree with that sentiment.

However, at some places the article goes over the top. This is really a pity, as those bits are not necessary for the overall argument. Moreover, those parts weaken the reading experience as much as a bunch of spelling mistakes would.

> Using “HTTP 404 Not Found” to notify about an unexisting resource sounds RESTful as heck, doesn’t it? Too bad: your nginx was misconfigured for 1 hour, so your API consumers got only 404 errors and purged hundreds of accounts, thinking they were deleted….

A non-existing resource doesn't mean it was deleted, but simply means it is not there - for whatever reason. Acting with deletion after receiving a 404 sound quite far fetched to me. (Except when mirroring, but then it would restore everything as soon as the configuration was fixed.)

Moreover, if the server does have active knowledge of the deleted status of a dataset, and wants to communicate that to a client, it would use 410 Gone. Only then the client has enough evidence to perform a deletion on their side.

> You want to use PUT to update your resource? OK, but some Holy Specifications state that the data input has to be equivalent to the representation received via a GET. So what do you do with the numerous read-only parameters returned by GET (creation time, last update time, server-generated token…)?

The PUT semantics only require it to be idempotent. That is, multiple identical PUTs should lead to the same result as a single PUT. The specs do not require that GET has to return the exact same value installed by PUT. Even more so, the specs actively discourage clients to make that assumption, as a different client - or any other event for that matter - could have changed the value in the meantime.


> A non-existing resource doesn't mean it was deleted, but simply means it is not there - for whatever reason.

There you have ambiguity of using http codes for representing application logic. Using any other http code will have the exact same problem - you can easily encounter a situation when http-meaning is accidentally confused with your-definition, this was just one example. The solution is to not mix them at all.


The site https://f-droid.org/ currently shows:

    Not Found
    
    The requested URL / was not found on this server.
This look more like a configuration error than anything else.


> several of which using 200GB of memory

I really, really hope you mean "200MB", although I honestly wouldn't be surprised if they managed to use 200GB if accidentally started on a beefy server.


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

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

Search: