A Pinterest kirúgta azokat a mérnököket, akik a Slackben követték nyomon a leépítéseket – mit mond ez az adatvédelemről, a bizalomról és a belső telemetriáról?

/Általános/ Által

A Pinterest állítólag elbocsátott két mérnököt, miután szkripteket írtak annak azonosítására, hogy mely munkatársakat távolítják el a belső eszközökből egy elbocsátás során – majd ezt a listát szélesebb körben is megosztották. Felületesen ez egy munkahelyi drámatörténet. Alatt egy szokatlanul világos esettanulmány arról, hogyan működnek a modern vállalatok: az identitásrendszerek az igazság forrásaként, a csevegőplatformok de facto szervezeti diagramokként, és a „belső adatok”, amelyek technikailag már jóval azelőtt elérhetők, hogy társadalmilag elfogadhatóvá válnának.

Az incidens túlmutat a Pinteresten, mivel ugyanazok az összetevők léteznek szinte minden tech cégnél: központosított identitás, Slack vagy Teams, HR rendszerek, valamint hosszú sor belső irányítópult és API. Amikor nyugodt idők járnak, senki sem gondolkodik túlságosan a megfigyelhetőség és a megfigyelés közötti határvonalon. Amikor elbocsátások történnek, ez a határvonal kivilágosodik.

Ebben a magyarázó anyagban megvizsgáljuk, hogy mi történhetett valószínűleg, miért csábító az ilyen jellegű követés, hol lépi át az etikai és politikai határokat, és mit tehetnek a szervezetek az adatvédelmi károk és az árnyék-információgyűjtés iránti vágy csökkentése érdekében.

Mi történt (és mit jelent valószínűleg a „forgatókönyv” kifejezés itt)

A BBC szerint a Pinterest azt állította, hogy „két mérnök egyéni szkripteket írt, amelyek jogosulatlanul fértek hozzá bizalmas vállalati információkhoz, hogy azonosítsák az összes elbocsátott alkalmazott helyét és nevét, majd ezt szélesebb körben megosztották”, ezt irányelvsértésnek és az érintett alkalmazottak adatvédelmi problémájának nevezve. A jelentés azt is leírja, hogy a mechanizmus egy belső kommunikációs eszközben, „mint a Slack” figyeli az alkalmazottak nevének eltávolítását vagy deaktiválását.

Sok vállalatnál a Slack (vagy hasonló) közvetlenül az identitásszolgáltatóhoz van kötve (Okta, Azure AD, Google Workspace stb.). Amikor egy fiókot letiltanak, egy kaszkád következik be: a hozzáférési tokenek lejárnak, a csoportok megváltoznak, és a felhasználó nem jelenik meg bizonyos címtárkeresésekben, csatornákban és integrációkban. Ha API-hozzáféréssel rendelkezik (akár csak olvasható), gyakran egyszerűen az állapotváltozások észlelésével kikövetkeztetheti, hogy kinek a fiókja lett megszüntetve:

  • Egy felhasználó eltűnik az „aktív felhasználók” listájáról.
  • A felhasználói profil inaktívvá válik.
  • Egy bot már nem tud nekik DM-et küldeni.
  • A tagságuk csatornákon vagy felhasználói csoportokonként változik.

Egy „szkriptnek” ebben az összefüggésben nem kell kifinomultnak lennie. Lehet néhány tucat sornyi kód, amely lekérdezi az API-t, összehasonlítja a tegnapi felhasználói listát a maival, és riasztást küld. Tisztán technikai szempontból ez ugyanaz a minta, amelyet a mérnökök a legitim operatív feladatokhoz használnak: két pillanatkép összehasonlítása a változások észlelése érdekében.

A különbség az, hogy mit észlelnek (emberek), miért észlelik (elbocsátások), és hová kerülnek az eredmények (széles körben megosztva).

Miért teszik ezt az alkalmazottak elbocsátások alatt?

Van egy kellemetlen igazság a leépítésekkel kapcsolatban: az emberek általában mellékes csatornákon keresztül értesülnek az esemény menetéről, mielőtt a vezetés bármit is tisztázna. Néha azért, mert a vezetés még nem tudja megosztani a részleteket. Néha pedig azért, mert a „még dolgozunk a részleteken” kifejezés eufemizmusa a „nem akarjuk elmondani” kifejezésre.

Tehát az alkalmazottak bármilyen jelre nyúlnak:

  • A barátok hirtelen elhallgatnak.
  • Eltűnnek a naptármeghívók.
  • A repókhoz való hozzáférés visszavonva.
  • A Slack állapota megváltozik, vagy a személy eltűnik a címtárból.

Ezeknek a jeleknek a követése önvédelemnek tűnhet. Az emberek tudni akarják:

  • Érinti ez a csapatomat?
  • Kirúgták a főnökömet?
  • Itt vannak még a legközelebbi munkatársaim?
  • Jól van a cég, vagy ez egy nagyobb átszervezés?

Ez a motiváció emberi és kiszámítható. De az kiszámítható viselkedés mégis lehet káros viselkedés.

Az adatvédelmi probléma: a leépítési állapot érzékeny információ

A munkaviszony megszüntetése nem csupán „munkaügyi érdekesség”. Érzékeny személyes információkat tartalmaz valakinek a foglalkoztatási státuszáról, amelyek gyakran kapcsolódnak a juttatásokhoz, a bevándorláshoz, az egészségbiztosításhoz és a jövőbeli munkalehetőségekhez.

Még ha egy vállalat nyilvánosan is tervezi bejelenteni a létszámcsökkentést, az egyének kilétét és tartózkodási helyét jellemzően csak a szükséges ismeret elve alapján hozzák nyilvánosságra:

  • HR és bérszámfejtési igények részletei.
  • Az IT-nek végre kell hajtania az offboardingot.
  • Jogi szükségletek a megfelelés biztosítására.
  • A vezetőknek közvetlenül kell kommunikálniuk a csapataikkal.

A felmondott alkalmazottak listájának széles körű, belső megosztása más tészta. Ez a következőket teheti:

  • Távolítsa el az érintett személy azon képességét, hogy irányítsa a történet menetét.
  • Felfedni valakinek a tartózkodási helyét vagy a csapathoz való tartozását.
  • Ösztönözz pletykákat és találgatásokat („előadás volt?”, „politikai jellegű volt?”).
  • Növeli a célzott zaklatás vagy doxing kockázatát a vállalaton kívül.

A Pinterest azon érvelése – miszerint megsértette volt kollégái magánéletét – nem pusztán PR. Ez egy valódi károkozás.

A biztonsági probléma: a hozzáférés-vezérlés nem ugyanaz, mint az engedélyezés

Sok belső rendszer durva jogosultságokkal működik: ha mérnök vagy, lekérdezhetsz egy könyvtárat vagy használhatsz egy belső API-t. Ez nem jelenti azt, hogy minden célra jogosult vagy használni.

Itt küzd sok szervezet. Olyan belső eszközöket építenek, amelyek:

  • Könnyen használható,
  • Erős,
  • Rosszul kormányozva.

És akkor a szabályzatra („ne tedd ezt”) támaszkodnak elsődleges védőkorlátként. Amikor nagy a nyomás, a kizárólag szabályzaton alapuló védőkorlátok kudarcot vallanak.

A NIST SP 800-53 egyike azoknak a szabványos katalógusoknak, amelyeket a szervezetek használnak a hozzáférés-vezérléshez és az auditáláshoz hasonló vezérlőcsaládok vizsgálatához. Anélkül, hogy elvesznénk a vezérlőazonosítókban, az alapötlet itt is egyértelműen érvényes: az adathozzáférést korlátozni, felügyelni és jogos üzleti célokra kell kötni – különösen az érzékeny információkategóriák esetében.

Más szóval: a „technikailag el tudod olvasni ezt” kifejezést soha nem szabad úgy értelmezni, hogy „rendben van, ha elolvasod ezt”.

A kulturális probléma: A Slack lett a szervezeti felépítés

A legtöbb vállalatnak ma már két párhuzamos valósága van:

  1. A formális valóság: HR rendszerek, jelentési vonalak, hivatalos bejelentések.
  2. A megélt valóság: Slack csatornák, csoportos DM-ek, GitHub-említések, ügyeleti rotációk.

Amikor valami megváltozik a formális rendszerben (például a munkatársak elbocsátása), az azonnal látható változásokat hoz létre a megélt rendszerben. Az alkalmazottak ezeket a változásokat igazságként értelmezik – néha erősebben, mint amennyire megbíznak a vezetői kommunikációban.

Ez az eltérés perverz ösztönzőt teremt:

  • Ha a vezetőség nem mondja el, mi történik,
  • A telemetriai szivárgások alapján fogod rekonstruálni.

Ez az incidens emlékeztetőül szolgál arra, hogy a „belső átláthatóság” nem csupán kommunikációs stratégia, hanem információbiztonsági stratégia is. Ha az emberek úgy érzik, hogy a valóságot ki kell építeniük a kiszivárogtatott információkból, akkor meg is fogják tenni.

Ahol a mérnökök átlépték a határt

Még ha átérzed is, hogy valaki miért írhat ilyen forgatókönyvet, legalább három világos határvonal átléphető:

1) Célhoz kötöttség

Ha az adatforrás „bizalmas vállalati információ”, akkor az elvárás az, hogy azt jogos üzleti funkcióra használják, nem pedig elbocsátási felderítésre.

A NIST adatvédelmi keretrendszere hangsúlyozza az adatvédelmi kockázatok kezelését és az egyéneket védő gyakorlatok alkalmazását. A gyakorlati fordítás így hangzik: „adatok gyűjtése és felhasználása meghatározott, jogos célokra, és az új károkat okozó másodlagos felhasználások elkerülése”.

Egy elbocsátott kollégák azonosítására szolgáló szkript szinte definíció szerint másodlagos felhasználású: a kilépési jelek a rendszerek védelmét és a HR-folyamatok végrehajtását szolgálják, nem pedig egy belső elbocsátási lista létrehozását.

2) Erősítés

Az emberek organikusan veszik észre az eltűnéseket a Slackben – ez környezeti információszivárgás.

Egy szkript a környezeti szivárgást strukturált adathalmazzá alakítja (nevek, helyszínek, valószínűsíthető csapatok, a megszüntetés időpontja). Ez az erősítés: a kár potenciálja meredeken megnő, amikor a homályos jelekből egy tiszta lista lesz.

3) Újraelosztás

A kimenet „szélesebb körű” megosztása az a lépés, amelyet nehéz puszta kíváncsiságként védeni. Új terjesztési csatornát hoz létre az érzékeny információk számára, és a szerzőket felelősségre vonja a későbbi visszaélésekért.

Amit a vállalatok tehetnek: csökkenthetik a szivárgást, növelhetik a bizalmat és szigoríthatják az ellenőrzéseket.

Téves az a tévhit, hogy a megoldás az, hogy „le kell zárni mindent”. A gyakorlatban három egymást kiegészítő lépésre van szükség: irányításra, technikai ellenőrzésre és kommunikációra.

1) A kilépési eseményeket bizalmasként kezeljük, és a tervezés során vegyük figyelembe az adatvédelmet

A kiszervezés elkerülhetetlenül megváltoztatja a rendszereket, de csökkentheti az információáramlást:

  • Minimalizálja a nyilvános címtárbeli változtatásokat, amíg a kommunikáció meg nem történik.
  • Kerüld a könnyen azonosítható tömeges felhasználó-eltávolításokat.
  • Fontold meg bizonyos, nem biztonsági szempontból kritikus frissítések órákkal történő késleltetését, hogy ne valós idejű leállási előrejelzésként működjenek.

A cél nem az, hogy örökre elrejtsük a valóságot. Az, hogy elkerüljük egy fájdalmas esemény kincsvadászattá válását.

2) Célalapú hozzáférés-vezérlés és naplózás hozzáadása

Ha a belső API-k képesek nagymértékben feltárni az alkalmazottak státuszváltozásait, akkor:

  • A hozzáférést azokra a szerepkörökre kell korlátozni, amelyeknek szükségük van rá.
  • A tömeges exportot indokolni kell.
  • A lekérdezéseket identitással és szándékkal kell naplózni.
  • Az automatizált közvélemény-kutatásoknak ki kell tűnniük.

Itt számít az „auditálás és elszámoltathatóság” szemlélete: ha egy szkript felsorolja a felhasználókat és riasztásokat küld, akkor észlelést kell indítania.

3) Legyen humánus kommunikációs terve a létszámleépítésekre

Az árnyékkövetés legfőbb mozgatórugója a bizonytalanság.

A vállalatok csökkenthetik a belső eszközök lemásolására irányuló késztetést, ha egyértelműek:

  • Mikor értesítik az érintett alkalmazottakat?
  • Mikor fogják értesíteni a csapatokat?
  • Mit lehet megosztani, és mikor?
  • Hová forduljanak az emberek ellenőrzött frissítésekért?

Ha a vezetés időszerű, konkrét információkat nyújt, akkor a „csináld magad” listák „igénye” csökken.

4) Biztosítson alkalmazottaknak egy engedélyezett módot az együttműködők ellenőrzésére

Ez finom, de fontos. Az emberek nemcsak kíváncsiak – megpróbálják összehangolni a munkájukat és érdeklődni a barátaik felől.

Egy egyszerű, engedélyezett címtári állapotüzenet („ez a fiók már nem aktív”) időbélyegek, hely vagy listák nélkül kielégíthetné az alapvető szükségleteket anélkül, hogy tömeges rekonstrukciót tenne lehetővé.

Egy szélesebb körű trend: a leépítések mint információbiztonsági stresszteszt

A leépítések a kormányzás gyenge pontjait mutatják fel, mivel a következőket hozzák létre:

  • érzékeny események sorozata,
  • magas érzelmi hőmérséklet,
  • és sok a hozzáférési lemorzsolódás.

Pontosan ilyenkor láthatjuk a szélsőséges eseteket: az alkalmazottak kihasználják a rendszereket, a vezetők improvizálnak, és az eszközöket olyan módon használják, amire senki sem számított.

Az olyan oldalak, mint a Layoffs.fyi, azért léteznek, mert az emberek független jelzéseket szeretnének kapni az iparágban zajló leépítések mértékéről. Egy vállalaton belül is ugyanez az igény fennáll – azzal a különbséggel, hogy a jelzések közvetlenebbek, és a tét személyes.

A lényeg

A Pinterest mérnökeinek elbocsátása a létszámleépítési skriptek miatt nem csak egy „ne legyél kíváncsi”. Figyelmeztetés arra, hogy a belső megfigyelhetőség belső felügyeletté válhat abban a pillanatban, amikor a szervezeti bizalom csökken.

Ha az eszközeiddel könnyen lehet az identitásváltozást elbocsátott munkatársak listájává alakítani, akkor az emberek ezt meg is teszik – különösen elbocsátások esetén. A megoldás nemcsak a forgatókönyvet író emberek megbüntetése, hanem olyan rendszerek és kommunikációs gyakorlatok kiépítése is, amelyek nem változtatják az elbocsátást adatszivárgássá, és amelyek a foglalkoztatás státuszát is bizalmas információként kezelik.

Források

Document Title
Pinterest fired engineers who tracked layoffs in Slack — what it says about privacy, trust, and internal telemetry
Pinterest fired engineers after scripts tracked layoffs via internal tools; why employment-status data is sensitive and how to prevent internal surveillance.
Title Attribute
oEmbed (JSON)
oEmbed (XML)
JSON
View all posts by Admin
How Apple’s Lockdown Mode can derail iPhone forensics — and why that’s the point
Senators grill Waymo and Tesla on robotaxi safety — what’s actually at stake
Page Content
Pinterest fired engineers who tracked layoffs in Slack — what it says about privacy, trust, and internal telemetry
Nature
Climate
/
General
/ By
Admin
Pinterest reportedly fired two engineers after they wrote scripts to identify which coworkers were being removed from internal tools during a layoff — and then shared that list more broadly. On the surface, this is a workplace drama story. Underneath, it’s an unusually clear case study in how modern companies actually run: identity systems as the source of truth, chat platforms as de facto org charts, and “internal data” that is technically accessible long before it is socially acceptable.
The incident matters beyond Pinterest because the same ingredients exist in almost every tech company: centralized identity, Slack or Teams, HR systems, and a long tail of internal dashboards and APIs. When times are calm, nobody thinks too hard about the line between observability and surveillance. When layoffs happen, that line lights up.
In this explainer, we’ll look at what likely happened, why it’s tempting to do this kind of tracking, where it crosses ethical and policy boundaries, and what organizations can do to reduce both privacy harm and the urge for shadow information-gathering.
What happened (and what “a script” probably means here)
According to the BBC, Pinterest said “two engineers wrote custom scripts improperly accessing confidential company information to identify the locations and names of all dismissed employees and then shared it more broadly,” calling it a policy violation and a privacy issue for affected staff. The reporting also describes the mechanism as watching for employee names being removed or deactivated inside an internal communication tool “like Slack.”
In many companies, Slack (or similar) is tied directly to the identity provider (Okta, Azure AD, Google Workspace, etc.). When an account is disabled, a cascade follows: access tokens expire, groups change, and the user stops appearing in certain directory searches, channels, and integrations. If you have API access (even read-only), you can often infer who was terminated simply by detecting state changes:
A user disappears from the “active users” list.
A user’s profile becomes deactivated.
A bot can no longer DM them.
Their membership changes across channels or user groups.
A “script” in this context doesn’t have to be sophisticated. It could be a few dozen lines of code polling an API, comparing yesterday’s user list to today’s, and emitting an alert. From a purely technical perspective, it’s the same pattern engineers use for legitimate operational tasks: diffing two snapshots to detect change.
The difference is what is being detected (people), why it’s being detected (layoffs), and where the results go (shared broadly).
Why employees do this during layoffs
There’s an uncomfortable truth about layoffs: people usually learn the shape of the event through side channels before leadership clarifies anything. Sometimes that’s because leadership can’t share details yet. Sometimes it’s because “we’re still working through the details” is a euphemism for “we don’t want to say.”
So employees reach for whatever signals exist:
Friends suddenly go silent.
Calendar invites vanish.
Access to repos is revoked.
Slack status flips, or the person disappears from the directory.
Tracking those signals can feel like self-defense. People want to know:
Is my team impacted?
Did my manager get cut?
Are my closest collaborators still here?
Is the company okay, or is this a larger restructuring?
That motivation is human and predictable. But predictable behavior can still be harmful behavior.
The privacy problem: layoff status is sensitive information
A termination event is not just “work trivia.” It’s sensitive personal information about someone’s employment status, often tied to benefits, immigration, health insurance, and future job prospects.
Even if a company plans to announce a headcount reduction publicly, the identity of the individuals and their locations is typically meant to be disclosed on a need-to-know basis:
HR and payroll need details.
IT needs to execute offboarding.
Legal needs to ensure compliance.
Managers need to communicate directly with their teams.
Broad internal sharing of a list of terminated employees is different. It can:
Remove the affected person’s ability to control the narrative.
Expose someone’s location or team affiliation.
Encourage gossip and speculation (“was it performance?” “was it political?”).
Increase the risk of targeted harassment or doxxing outside the company.
Pinterest’s framing — that it violated former colleagues’ privacy — is not just PR. It’s a real category of harm.
The security problem: access control isn’t the same as authorization
Many internal systems work on coarse permissions: if you’re an engineer, you might be able to query a directory or use an internal API. That doesn’t mean you’re authorized to use it for every purpose.
This is where a lot of organizations struggle. They build internal tools that are:
Easy to use,
Powerful,
Poorly governed.
And then they rely on policy (“don’t do that”) as the primary guardrail. When the pressure is high, policy-only guardrails fail.
NIST SP 800-53 is one of the standard catalogs organizations use to think about control families like access control and auditing. Even without getting lost in control IDs, the basic idea applies cleanly here: data access should be constrained, monitored, and attributable to legitimate business purposes — especially for sensitive categories of information.
In other words: “you can technically read this” should never be treated as “it’s fine for you to read this.”
The cultural problem: Slack has become the org chart
Most companies now have two parallel realities:
The formal reality: HR systems, reporting lines, official announcements.
The lived reality: Slack channels, group DMs, GitHub mentions, on-call rotations.
When something changes in the formal system (like offboarding), it immediately produces visible artifacts in the lived system. Employees interpret those artifacts as truth — sometimes more strongly than they trust leadership communications.
That mismatch creates a perverse incentive:
If leadership won’t tell you what’s happening,
you will reconstruct it from whatever telemetry leaks.
This incident is a reminder that “internal transparency” is not just a comms strategy — it’s also an information-security strategy. If people feel they must piece together reality from leaks, they will.
Where the engineers crossed the line
Even if you empathize with why someone might build such a script, there are at least three bright lines that get crossed:
1) Purpose limitation
If the data source is “confidential company information,” the expectation is that it’s used for a legitimate business function, not for layoff reconnaissance.
NIST’s Privacy Framework emphasizes managing privacy risk and using practices that protect individuals. A practical translation is “collect and use data for specific, legitimate purposes, and avoid secondary uses that create new harms.”
A script to identify terminated colleagues is almost definitionally a secondary use: the offboarding signals exist to protect systems and execute HR processes, not to generate an internal layoff list.
2) Amplification
People notice disappearances in Slack organically — that’s ambient information leakage.
A script turns ambient leakage into a structured dataset (names, locations, likely teams, time of termination). That is amplification: the harm potential rises sharply when vague signals become a clean list.
3) Redistribution
Sharing the output “more broadly” is the step that makes it hard to defend as mere curiosity. It creates a new distribution channel for sensitive information and makes the authors accountable for downstream misuse.
What companies can do: reduce leakage, increase trust, and tighten controls
There’s a misconception that the solution is “lock everything down.” In practice you need three complementary moves: governance, technical controls, and communication.
1) Treat offboarding events as sensitive and design for privacy
Offboarding inevitably changes systems, but you can reduce the informational exhaust:
Minimize public-facing directory changes until communications occur.
Avoid mass user removals that are easy to diff.
Consider delaying certain non-security-critical updates by hours so they don’t act as a real-time layoff feed.
The goal isn’t to hide reality forever. It’s to avoid turning a painful event into a scavenger hunt.
2) Add purpose-based access controls and logging
If internal APIs can reveal employee status changes at scale, then:
Access should be scoped to roles that need it.
Bulk export should require justification.
Queries should be logged with identity and intent.
Automated polling should stand out.
This is where the “audit and accountability” mindset matters: if a script is enumerating users and emitting alerts, it should trigger detection.
3) Have a humane comms plan for layoffs
The biggest driver of shadow tracking is uncertainty.
Companies can reduce the impulse to scrape internal tools by being explicit:
When will impacted employees be told?
When will teams be informed?
What can be shared, and when?
Where should people go for verified updates?
If leadership provides timely, specific information, the “need” for DIY lists drops.
4) Give employees a sanctioned way to check on collaborators
This is subtle but important. People are not only curious — they’re trying to coordinate work and check on friends.
A simple, sanctioned directory status message (“this account is no longer active”) without timestamps, location, or lists could satisfy basic needs without enabling mass reconstruction.
A wider trend: layoffs as an information-security stress test
Layoffs reveal weak points in governance because they create:
a burst of sensitive events,
a high emotional temperature,
and a lot of access churn.
That’s exactly when you see edge cases: employees scraping systems, managers improvising, and tools being used in ways nobody designed for.
Sites like Layoffs.fyi exist because people want an independent signal about the scale of cuts in the industry. Inside a company, that same need exists — except the signals are more direct and the stakes are personal.
Bottom line
Pinterest firing engineers for scripting layoff tracking isn’t just “don’t be nosy.” It’s a warning that internal observability can become internal surveillance the moment organizational trust drops.
If your tooling makes it easy to turn identity churn into a list of terminated coworkers, people will do it — especially during layoffs. The fix isn’t only punishing the people who wrote the script; it’s building systems and communication practices that don’t turn offboarding into a data leak, and that treat employment status as the sensitive information it is.
Sources
https://www.bbc.com/news/articles/cn0k670n0ydo
https://layoffs.fyi/
https://www.nist.gov/privacy-framework
https://csrc.nist.gov/pubs/sp/800/53/r5/final
←
Previous Post
Next Post
→
oEmbed (JSON)
oEmbed (XML)
JSON
View all posts by Admin
How Apple’s Lockdown Mode can derail iPhone forensics — and why that’s the point
Senators grill Waymo and Tesla on robotaxi safety — what’s actually at stake
Pinterest fired engineers after scripts tracked layoffs via internal tools; why employment-status data is sensitive and how to prevent internal surveillance.
Document Title
Page not found - Florin.blog
Image Alt
Florin.blog
Title Attribute
Florin.blog » Feed
RSD
Skip to content
Placeholder Attribute
Search...
Page Content
Page not found - Florin.blog
Skip to content
Home
Blog
Garden Decor
Indoor
Main Menu
This page doesn't seem to exist.
It looks like the link pointing here was faulty. Maybe try searching?
Search for:
Search
Quick Links
Outdoors
About
Contact
Explore
Bestsellers
Hot deals
Best of The Year
Featured
Gift Cards
Help
Privacy Policy
Disclaimer
: As an Amazon Associate, we earn from qualifying purchases — at no extra cost to you.
Florin.blog
Florin.blog » Feed
RSD
Search...
a Magyar