(The issues described in this post have been fixed, I have not exhaustively researched whether any other issues exist)
Feeld is a dating app aimed largely at alternative relationship communities (think "classier Fetlife" for the most part), so unsurprisingly it's fairly popular in San Francisco. Their website makes
the claim:
Can people see what or who I'm looking for?
No. You're the only person who can see which genders or sexualities you're looking for. Your curiosity and privacy are always protected.
which is based on you being able to restrict searches to people of specific genders, sexualities, or relationship situations. This sort of claim is one of those things that just sits in the back of my head worrying me, so I checked it out.
First step was to grab a copy of the Android APK (there are multiple sites that scrape them from the Play Store) and run it through
apk-mitm - Android apps by default don't trust any additional certificates in the device certificate store, and also frequently implement certificate pinning. apk-mitm pulls apart the apk, looks for known http libraries, disables pinning, and sets the appropriate manifest options for the app to trust additional certificates. Then I set up
mitmproxy, installed the cert on a test phone, and installed the app. Now I was ready to start.
What became immediately clear was that the app was using
graphql to query. What was a little more surprising is that it appears to have been implemented such that there's no server state - when browsing profiles, the client requests a batch of profiles along with a list of profiles that the client has already seen. This has the advantage that the server doesn't need to keep track of a session, but also means that queries just keep getting larger and larger the more you swipe. I'm not a web developer, I have absolutely no idea what the tradeoffs are here, so I point this out as a point of interest rather than anything else.
Anyway. For people unfamiliar with graphql, it's basically a way to query a database and define the set of fields you want returned. Let's take the example of requesting a user's profile. You'd provide the profile ID in question, and request their bio, age, rough distance, status, photos, and other bits of data that the client should show. So far so good. But what happens if we request other data?
graphql supports
introspection to request a copy of the database schema, but this feature is optional and was disabled in this case. Could I find this data anywhere else? Pulling apart the apk revealed that it's a
React Native app, so effectively a framework for allowing writing of native apps in Javascript. Sometimes you'll be lucky and find the actual Javascript source there, but these days it's more common to find
Hermes blobs. Fortunately
hermes-dec exists and does a decent job of recovering something that approximates the original input, and from this I was able to find various lists of database fields.
So, remember that original FAQ statement, that your desires would never be shown to anyone else? One of the fields mentioned in the app was "lookingFor", a field that wasn't present in the default profile query. What happens if we perform the incredibly complicated hack of exporting a profile query as a curl statement, add "lookingFor" into the set of requested fields, and run it?
Oops.
So, point 1 is that you can't simply protect data by having your client not ask for it - private data must never be released. But there was a whole separate class of issue that was an even more obvious issue.
Looking more closely at the profile data returned, I noticed that there were fields there that weren't being displayed in the UI. Those included things like "ageRange", the range of ages that the profile owner was interested in, and also whether the profile owner had already "liked" or "disliked" your profile (which means a bunch of the profiles you see may already have turned you down, but the app simply didn't show that). This isn't ideal, but what was more concerning was that profiles that were flagged as
hidden were still being sent to the app and then just not displayed to the user. Another example of this is that the app supports associating your profile with profiles belonging to partners - if one of those profiles was then hidden, the app would stop showing the partnership, but was still providing the profile ID in the query response and querying that ID would still show the hidden profile contents.
Reporting this was inconvenient. There was no security contact listed on the website or in the app. I ended up finding Feeld's head of trust and safety on Linkedin, paying for a month of Linkedin Pro, and messaging them that way. I was then directed towards a HackerOne program with a link to terms and conditions that 404ed, and it took a while to convince them I was uninterested in signing up to a program without explicit terms and conditions. Finally I was just asked to email security@, and successfully got in touch. I heard nothing back, but after prompting was told that the issues were fixed - I then looked some more, found another example of the same sort of issue, and eventually that was fixed as well. I've now been informed that work has been done to ensure that this entire class of issue has been dealt with, but I haven't done any significant amount of work to ensure that that's the case.
You can't trust clients. You can't give them information and assume they'll never show it to anyone. You can't put private data in a database with no additional acls and just rely on nobody ever asking for it. You also can't find a single instance of this sort of issue and fix it without verifying that there aren't other examples of the same class. I'm glad that Feeld engaged with me earnestly and fixed these issues, and I really do hope that this has altered their development model such that it's not something that comes up again in future.
(Edit to add: as far as I can tell, pictures tagged as "private" which are only supposed to be visible if there's a match were appropriately protected, and while there is a "location" field that contains latitude and longitude this appears to only return 0 rather than leaking precise location. I also saw no evidence that email addresses, real names, or any billing data was leaked in any way)
comments
Dear Debian community,
this are my bits from DPL for August.
Happy Birthday Debian
On 16th of August Debian celebrated its 31th birthday. Since I'm
unable to write a better text than our great publicity team I'm
simply linking to their article for those who might have missed it:
https://bits.debian.org/2024/08/debian-turns-31.html
Removing more packages from unstable
Helmut Grohne argued for more aggressive package removal and
sought consensus on a way forward. He provided six examples of processes
where packages that are candidates for removal are consuming valuable
person-power. I d like to add that the Bug of the Day initiative (see
below) also frequently encounters long-unmaintained packages with popcon
votes sometimes as low as zero, and often fewer than ten.
Helmut's email included a list of packages that would meet the suggested
removal criteria. There was some discussion about whether a popcon vote
should be included in these criteria, with arguments both for and
against it. Although I support including popcon, I acknowledge that
Helmut has a valid point in suggesting it be left out.
While I ve read several emails in agreement, Scott Kitterman made
a valid point "I don't think we need more process. We just need
someone to do the work of finding the packages and filing the bugs." I
agree that this is crucial to ensure an automated process doesn t lead
to unwanted removals. However, I don t see "someone" stepping up to file
RM bugs against other maintainers' packages. As long as we have strict
ownership of packages, many people are hesitant to touch a package, even
for fixing it. Asking for its removal might be even less well-received.
Therefore, if an automated procedure were to create RM bugs based on
defined criteria, it could help reduce some of the social pressure.
In this aspect the opinion of Niels Thykier is interesting: "As
much as I want automation, I do not mind the prototype starting as a
semi-automatic process if that is what it takes to get started."
The urgency of the problem to remove packages was put by CharlesPlessy
into the words: "So as of today, it is much less work to
keep a package rotting than removing it." My observation when trying to
fix the Bug of the Day exactly fits this statement.
I would love for this discussion to lead to more aggressive removals
that we can agree upon, whether they are automated, semi-automated, or
managed by a person processing an automatically generated list
(supported by an objective procedure). To use an analogy: I ve found
that every image collection improves with aggressive pruning. Similarly,
I m convinced that Debian will improve if we remove packages that no
longer serve our users well.
DEP14 / DEP18
There are two DEPs that affect our workflow for maintaining
packages particularly for those who agree on using Git for Debian
packages. DEP-14 recommends a standardized layout for Git packaging
repositories, which benefits maintainers working across teams and makes
it easier for newcomers to learn a consistent repository structure.
DEP-14 stalled for various reasons. Sam Hartman suspected it might
be because 'it doesn't bring sufficient value.' However, the assumption
that git-buildpackage is incompatible with DEP-14 is incorrect, as
confirmed by its author, Guido G nther. As one of the two key tools
for Debian Git repositories (besides dgit) fully supports DEP-14, though
the migration from the previous default is somewhat complex.
Some investigation into mass-converting older formats to DEP-14 was
conducted by the Perl team, as Gregor Hermann pointed out..
The discussion about DEP-14 resurfaced with the suggestion of DEP-18.
Guido G nther proposed the title Encourage Continuous Integration and Merge
Request-Based Collaboration for Debian Packages ,
which more accurately reflects the DEP's technical intent.
Otto Kek l inen, who initiated DEP-18 (thank you, Otto), provided a good
summary of the current status. He also assembled a very helpful
overview of Git and GitLab usage in other Linux distros.
More Salsa CI
As a result of the DEP-18 discussion, Otto Kek l inen suggested
implementing Salsa CI for our top popcon packages.
I believe it would be a good idea to enable CI by default across Salsa
whenever a new repository is created.
Progress in Salsa migration
In my campaign, I stated that I aim to reduce the number of
packages maintained outside Salsa to below 2,000. As of March 28, 2024,
the count was 2,368. Today, it stands at 2,187 (UDD query: 
All but about four hours of my Debian contributions this month were
Another short status update of what happened on my side last month.
Quite a bit of time went
into helping organize the 
Warning: If you're not into meat, you might want to skip the
rest of this...
This year, I turned 50. Wow. Lots of friends and family turned up
to help me celebrate, with a BBQ (of course!). I was very grateful for
a lovely set of gifts from those awesome people, and I have a number
of driving experiences to book in the next year or so. I'm going to
have so much fun driving silly cars on and off road!
However, the most surprising gift was
something totally different - a full-day course of
hands-on pork butchery. I was utterly bemused - I've never
considered doing anything like this at all, and I'd certainly never
talked to friends about anything like it either. I was shocked, but in
a good way!
So, two weekends back Jo and I went over
to 
At the beginning of the day, we each started with half a pig. Over
the next several hours, we steadily worked our way through a series of
cuts with knife and saw, making the remaining pig smaller and smaller
as we went.
We finished the day with three sets of meat. First, a stack of
vacuum-packed joints, chops and steaks ready for cooking and eating at
home. Second: a box of off-cuts that we minced and made into sausages
at the end of the day. Finally: a bag of skin and bones. Our friend's
dog got some of the bones, and Jo turned a lot of the skin into
crackling that we shared with friends at the OMGWTFBBQ the next
weekend.
This was an amazing day. Massive thanks to my good friend Chris
Walker for suggesting this gift. As I told David on the day: this was
the most fun surprise gift I've ever received. Good hands-on teaching
in a new craft is an incredible thing to experience, and I can't
recommend this course highly enough.
Around a decade ago, I was happy to learn about bcache a Linux block cache system that implements tiered storage (like a pool of hard disks with SSDs for cache) on Linux. At that stage, ZFS on Linux was nowhere close to where it is today, so any progress on gaining more ZFS features in general Linux systems was very welcome. These days we care a bit less about tiered storage, since any cost benefit in using anything else than nvme tends to quickly evaporate compared to time you eventually lose on it.
In 2015, it was announced that bcache would grow into its own filesystem. This was particularly exciting and it caused quite a buzz in the Linux community, because it brought along with it more features that compare with 
por Allythy
O Debian Day um evento anual que celebra o anivers rio do Debian, uma das
distribui es GNU/Linux mais importante do Software Livre, criada em 16 de
Agosto de 1993, por Ian Murdock.
No ltimo s bado (17/08/2024) no Sebrae-RN comemoramos os 31 anos Debian em
Natal, no Rio Grande do Norte. A celebra o, foi organizada pela
PotiLivre(Comunidade Potiguar de Software Livre), destacou os 31 anos de
hist ria do Debian. O evento contou com algumas palestras e muitas discuss es
sobre Software Livre. Tivemos 70 inscri es, 40 estiverem presentes.
O Debian Day em Natal foi uma ocasi o para celebrar a trajet ria do Debian e
refor ar a import ncia do Software Livre.
Palestrantes
Agradecemos imensamente a Isaque Barbosa Martins, Eduardo de Souza Paix o,
Fernando Guisso,que palestraram nessa edi o! Obrigado por compartilhar tanto
conhecimento com a comunidade. Esperamos ver voc s novamente em futuros
encontros!
Essa edi o do Debina Day Natal foi organizada por: Allythy, Clara Nobre,
Gabriel Damazio e Marcel Ribeiro.
Release 0.6.37 of the 
Like each month, have a look at the work funded by 
To ease my nerves, I struck up a conversation with a man seated nearby who was
also traveling to Abu Dhabi for work. He provided helpful information about
safety and transportation in Abu Dhabi, which reassured me. With the boarding
process complete and my anxiety somewhat eased. I found my window seat on the
flight and settled in, excited for the journey ahead. Next to me was a young
man from Ranchi(Zarkhand, India), heading to Abu Dhabi for work at a mining
factory. We had an engaging conversation about work culture in Abu Dhabi and
recruitment from India.
Upon arriving in Abu Dhabi, I completed my transit, collected my luggage, and
began finding my way to the hotel 
I reached Tirana, Albania after a six hours flight, feeling exhausted and I was
suffering from a headache. The air pressure had blocked my ears, and jet lag
added to my fatigue. After collecting my checked luggage, I headed to the first
ATM machine at the airport. Struggling to insert my card, I asked a nearby
gentleman for help. He tried his best, but my card got stuck inside the
machine. Panic set in as I worried about how I would survive without money.
Taking a deep breath, I found an airport employee and explained the situation.
The gentleman stayed with me, offering support and repeatedly apologizing for
his mistake. However, it wasn t his fault, the ATM was out of order, which I
hadn t noticed. My focus was solely on retrieving my ATM card. The airport
employee worked diligently, using a hairpin to carefully extract my card.
Finally, the card was freed, and I felt an immense sense of relief, grateful
for the help of these kind strangers. I used another ATM, successfully withdrew
money, and then went to an airport mobile SIM shop to buy a new SIM card for
local internet and connectivity.
I found my top bunk bed, only to realize I had booked a mixed-gender
dormitory. This detail had completely escaped my notice during the booking
process. I felt unsure about how to handle the situation. Coincidentally,
my experience mirrored what Kangana faced in the movie Queen .
Feeling acidic due to an empty stomach and the exhaustion of heavy
traveling, I wasn t up to cooking in the hostel s kitchen.
I asked the front desk about the nearest restaurant. It was nearly 9:30 PM,
and the streets were deserted. To avoid any mishaps like in the movie
Queen, I kept my passport securely locked in my bag, ensuring it wouldn t
be a victim of theft.
Venturing out for dinner, I felt uneasy on the quiet streets. I eventually
found a restaurant recommended by the hostel, but the menu was almost
entirely non-vegetarian. I struggled to ask about vegetarian options and was
uncertain if any dishes contained eggs, as some people consider eggs to be
vegetarian. Feeling frustrated and unsure, I left the restaurant without
eating.
I noticed a nearby grocery store that was about to close and managed to get
a few extra minutes to shop. I bought some snacks, wafers, milk, and tea
bags (though I couldn t find tea powder to make Indian-style tea). Returning
to the hostel, I made do with wafers, cookies, and milk for dinner. That day
was incredibly tough for me, I filled with exhaustion and struggle in a new
country, I was on the verge of tears .
I made a video call home before sleeping on the top bunk bed. It was a new
experience for me, sharing a room with both unknown men and women. I kept my
passport safe inside my purse and under my pillow while sleeping, staying
very conscious about its security.
I took a bus from Shkod r to the southern part of Albania, heading to
Sarand . The journey lasted about five to six hours, and I had booked a stay
at 
