Client-side filtering of private data is a bad idea

The title reads like: "Why jumping from a bridge is a bad idea". Does this needs to be stated?

Caveat to the title: Except for local client-side data <i>emissions</i>. Filtering private data before it gets sent from your device in the first place is a good idea.

I wonder how many backends are just pure CRUD with all business rules implemented on the frontend? Scary to think. I&#x27;m forever having to tell devs that form validation in js isn&#x27;t enough, you need to do it on the backend too (or, preferably, only). This article is about reading data you shouldn&#x27;t be able to, but my strong suspicion is a bunch of stuff out there will let you write stuff you shouldn&#x27;t be able to as well.

This is a risk common to all &quot;fat clients&quot;, when the same team develops both the server code and the client code: it&#x27;s easy to forget that, unlike the server code, the client code cannot be trusted.

Translated: implementing a server query interface with insufficient access controls is a bad idea.<p>The article is mostly about the resulting security by obscurity being broken.

They should learn about bloom filters. Could kill two birds with one stone, fix leaking the preferences via the swipe list and fix the ever growing query problem.

I&#x27;ve always been a bit suspicious that mistakes like this are easier in GraphQL than older REST (or even SOAP) models because GraphQL is designed for more frontend-driven development. Obviously this is just one example, but it was interesting that it involved &quot;hidden&quot; GraphQL data.

Long post to say that yet another application had an access control issue which was being masked because the access control was implemented on the client.<p>Incredibly common in my experience in the security field.

Oh I see, the claim is “we don’t do the result filtering ourselves so we don’t know what you’re looking for” but that is done by … taking your filters and broadcasting them to everybody?<p>So they’ve removed the server from the filtering process but made the privacy implications far worse.

403 Forbidden

I don&#x27;t understand this idea that you can do anything &quot;privately&quot; on a device designed to collect and leak your personal information whose admin is a corporation that can make changes to the system at any time without your consent or awareness, and where multiple parties (carrier, and manufactures) have privileged access to do the same, and where your own access is extremely limited and controlled. The entire system is totally insecure and non-private by design.<p>The idea that dating app could prevent your preferences from being collected seems unlikely to me too. If people are posting profiles and messaging each other on a platform, that platform is going to have no problem learning what their interests are. They don&#x27;t need to know what you&#x27;re searching for, as long as they know who you&#x27;re finding.

Ehm... A long time developer do think data sent on someone else machine can still be &quot;private&quot;? Ehm... Mh... I have some issue to find a politically correct way to state the fact that no damn laws can &quot;protect&quot; people who send anything to a third party...<p>BTW if some user of a dating service is concerned about his&#x2F;her own searches... More than beings scared about &quot;potential client-side leaks other dating service user might harvest&quot; try to concentrate on how much personal dating interests the service can harvest and eventually re-sell, if not &quot;the service&quot; just some working for it and having some side business...