Pinterest zwolnił inżynierów, którzy śledzili zwolnienia w Slacku – co to mówi o prywatności, zaufaniu i wewnętrznej telemetrii

/Ogólny/ Przez

Pinterest podobno zwolnił dwóch inżynierów po tym, jak napisali skrypty, które miały identyfikować współpracowników usuwanych z narzędzi wewnętrznych podczas redukcji etatów – a następnie udostępnili tę listę szerszemu gronu. Na pierwszy rzut oka to dramatyczna historia w miejscu pracy. W głębi duszy to niezwykle czytelne studium przypadku pokazujące, jak faktycznie działają współczesne firmy: systemy tożsamości jako źródło prawdy, platformy czatów jako de facto schematy organizacyjne i „dane wewnętrzne”, które są technicznie dostępne na długo przed tym, zanim zostaną społecznie akceptowalne.

Ten incydent ma znaczenie wykraczające poza Pinterest, ponieważ te same elementy występują w niemal każdej firmie technologicznej: scentralizowana tożsamość, Slack lub Teams, systemy HR oraz długi ogon wewnętrznych paneli sterowania i interfejsów API. W spokojnych czasach nikt nie zastanawia się zbytnio nad granicą między obserwowalnością a inwigilacją. Kiedy dochodzi do zwolnień, ta granica się rozjaśnia.

W tym artykule wyjaśnimy, co najprawdopodobniej się wydarzyło, dlaczego warto stosować tego rodzaju śledzenie, w jakich sytuacjach przekracza ono granice etyczne i polityczne oraz co organizacje mogą zrobić, aby ograniczyć zarówno naruszenia prywatności, jak i potrzebę gromadzenia informacji w ukryciu.

Co się wydarzyło (i co prawdopodobnie oznacza tutaj „scenariusz”)

Według BBC, Pinterest poinformował, że „dwóch inżynierów napisało niestandardowe skrypty, które nielegalnie uzyskiwały dostęp do poufnych informacji firmy, aby zidentyfikować lokalizacje i nazwiska wszystkich zwolnionych pracowników, a następnie udostępniły je szerszemu gronu odbiorców”, nazywając to naruszeniem polityki i zagrożeniem prywatności pracowników. W raporcie opisano również mechanizm monitorowania usuwania lub dezaktywacji nazwisk pracowników w wewnętrznym narzędziu komunikacyjnym „takim jak Slack”.

W wielu firmach Slack (lub podobny) jest bezpośrednio powiązany z dostawcą tożsamości (Okta, Azure AD, Google Workspace itp.). Wyłączenie konta powoduje kaskadę zdarzeń: tokeny dostępu wygasają, grupy ulegają zmianie, a użytkownik przestaje pojawiać się w niektórych wyszukiwaniach katalogowych, kanałach i integracjach. Jeśli masz dostęp do API (nawet tylko do odczytu), często możesz wywnioskować, kto został usunięty, po prostu wykrywając zmiany stanu:

  • Użytkownik znika z listy „aktywnych użytkowników”.
  • Profil użytkownika zostaje dezaktywowany.
  • Bot nie może już wysyłać do nich wiadomości prywatnych.
  • Ich członkostwo zmienia się w zależności od kanału lub grupy użytkowników.

„Skrypt” w tym kontekście nie musi być skomplikowany. Może to być kilkadziesiąt linijek kodu odpytujących API, porównujących wczorajszą listę użytkowników z dzisiejszą i generujących alert. Z czysto technicznego punktu widzenia, jest to ten sam wzorzec, którego inżynierowie używają do wykonywania legalnych zadań operacyjnych: porównywania dwóch migawek w celu wykrycia zmian.

Różnica polega na tym, co jest wykrywane (ludzie), dlaczego jest wykrywane (zwolnienia) i dokąd trafiają wyniki (szeroko udostępniane).

Dlaczego pracownicy tak robią podczas zwolnień

Istnieje niewygodna prawda o zwolnieniach: ludzie zazwyczaj dowiadują się o przebiegu zdarzenia z kanałów bocznych, zanim kierownictwo cokolwiek wyjaśni. Czasami dzieje się tak dlatego, że kierownictwo nie może jeszcze podzielić się szczegółami. Czasami dzieje się tak dlatego, że „wciąż dopracowujemy szczegóły” to eufemizm oznaczający „nie chcemy nic powiedzieć”.

Pracownicy zatem reagują na wszelkie sygnały, jakie istnieją:

  • Przyjaciele nagle milkną.
  • Zaproszenia w kalendarzu znikają.
  • Dostęp do repozytoriów został cofnięty.
  • Status Slacka ulega zmianie lub dana osoba znika z katalogu.

Śledzenie tych sygnałów może wydawać się samoobroną. Ludzie chcą wiedzieć:

  • Czy mój zespół zostanie objęty tą zmianą?
  • Czy mój menedżer został zwolniony?
  • Czy moi najbliżsi współpracownicy nadal tu są?
  • Czy firma jest w porządku, czy jest to raczej większa restrukturyzacja?

Ta motywacja jest ludzka i przewidywalna. Jednak przewidywalne zachowanie może być nadal szkodliwe.

Problem prywatności: status zwolnienia to informacja wrażliwa

Zdarzenie związane ze zwolnieniem z pracy to nie tylko „błahostka”. To poufne informacje osobiste dotyczące czyjegoś statusu zatrudnienia, często powiązane z zasiłkami, imigracją, ubezpieczeniem zdrowotnym i przyszłymi perspektywami zawodowymi.

Nawet jeśli firma planuje publicznie ogłosić redukcję zatrudnienia, tożsamość poszczególnych osób i ich lokalizacje powinny być zazwyczaj ujawniane wyłącznie w ramach zasady ograniczonego dostępu:

  • Dział kadr i płac potrzebuje szczegółów.
  • Dział IT musi wykonać offboarding.
  • Potrzeby prawne w celu zapewnienia zgodności.
  • Menedżerowie muszą komunikować się bezpośrednio ze swoimi zespołami.

Szerokie, wewnętrzne udostępnianie listy zwolnionych pracowników jest inne. Może:

  • Odbierz osobie dotkniętej atakiem możliwość kontrolowania narracji.
  • Ujawnij czyjąś lokalizację lub przynależność do drużyny.
  • Zachęcaj do plotek i spekulacji („czy to był występ?”, „czy to była sprawa polityczna?”).
  • Zwiększa ryzyko celowego nękania lub ujawniania danych osobowych osób trzecich poza firmą.

Oświadczenie Pinteresta, że ​​naruszył prywatność byłych współpracowników, to nie tylko PR. To realna kategoria krzywdy.

Problem bezpieczeństwa: kontrola dostępu nie jest tym samym, co autoryzacja

Wiele systemów wewnętrznych działa na podstawie uprawnień wstępnych: jeśli jesteś inżynierem, możesz wysłać zapytanie do katalogu lub skorzystać z wewnętrznego API. Nie oznacza to jednak, że masz prawo go używać do każdego celu.

To właśnie z tym zmaga się wiele organizacji. Tworzą one wewnętrzne narzędzia, które:

  • Łatwy w użyciu,
  • Potężny,
  • Słabo rządzone.

A potem opierają się na zasadach („nie rób tego”) jako na głównej barierze ochronnej. Przy dużej presji, bariery oparte wyłącznie na zasadach zawodzą.

NIST SP 800-53 to jeden ze standardowych katalogów, z których korzystają organizacje, rozważając rodziny kontroli, takie jak kontrola dostępu i audyt. Nawet bez zagłębiania się w identyfikatory kontroli, podstawowa idea ma tu wyraźne zastosowanie: dostęp do danych powinien być ograniczony, monitorowany i przypisany do uzasadnionych celów biznesowych – zwłaszcza w przypadku wrażliwych kategorii informacji.

Innymi słowy: stwierdzenia „technicznie rzecz biorąc, możesz to przeczytać” nigdy nie należy rozumieć jako „możesz to przeczytać”.

Problem kulturowy: Slack stał się schematem organizacyjnym

Większość firm ma obecnie dwie równoległe rzeczywistości:

  1. Rzeczywistość formalna: systemy kadrowe, struktury raportowania, oficjalne ogłoszenia.
  2. Rzeczywistość w praktyce: kanały Slack, grupowe wiadomości prywatne, wzmianki na GitHubie, dyżury.

Kiedy coś zmienia się w systemie formalnym (jak np. offboarding), natychmiast powoduje to widoczne artefakty w systemie rzeczywistym. Pracownicy interpretują te artefakty jako prawdę – czasami silniej niż ufają komunikatom kierownictwa.

Ta rozbieżność tworzy perwersyjną zachętę:

  • Jeśli przywódcy nie powiedzą ci, co się dzieje,
  • zrekonstruujesz go na podstawie wycieków danych telemetrycznych.

Ten incydent przypomina, że ​​„przejrzystość wewnętrzna” to nie tylko strategia komunikacyjna – to także strategia bezpieczeństwa informacji. Jeśli ludzie poczują, że muszą poskładać rzeczywistość na podstawie przecieków, to tak właśnie zrobią.

Gdzie inżynierowie przekroczyli granicę

Nawet jeśli zrozumiesz, dlaczego ktoś mógł stworzyć taki scenariusz, istnieją co najmniej trzy wyraźne granice, których nie można przekroczyć:

1) Ograniczenie celu

Jeśli źródłem danych są „poufne informacje firmy”, oczekuje się, że będą one wykorzystywane do uzasadnionych celów biznesowych, a nie do celów rozpoznania zwolnień.

Ramy Prywatności NIST kładą nacisk na zarządzanie ryzykiem naruszenia prywatności i stosowanie praktyk chroniących jednostki. W praktyce oznacza to „gromadzenie i wykorzystywanie danych do określonych, uzasadnionych celów oraz unikanie wtórnego wykorzystania, które może prowadzić do nowych szkód”.

Skrypt służący do identyfikacji zwolnionych współpracowników ma niemal z definicji drugorzędne zastosowanie: sygnały zwolnienia istnieją w celu ochrony systemów i realizacji procesów HR, a nie w celu generowania wewnętrznej listy zwolnień.

2) Wzmocnienie

Ludzie zauważają zniknięcia na Slacku naturalnie — to tzw. wyciek informacji środowiskowych.

Skrypt przekształca wyciek danych środowiskowych w ustrukturyzowany zbiór danych (nazwy, lokalizacje, prawdopodobne zespoły, czas zakończenia). To jest wzmocnienie: potencjał szkód gwałtownie rośnie, gdy niejasne sygnały stają się czystą listą.

3) Redystrybucja

„Szersze” udostępnianie wyników to krok, który utrudnia ich obronę jako zwykłej ciekawości. Tworzy to nowy kanał dystrybucji poufnych informacji i nakłada na autorów odpowiedzialność za dalsze niewłaściwe wykorzystanie.

Co mogą zrobić firmy: zmniejszyć wycieki, zwiększyć zaufanie i zaostrzyć kontrolę

Panuje błędne przekonanie, że rozwiązaniem jest „wszystko zamknąć”. W praktyce potrzebne są trzy uzupełniające się działania: zarządzanie, kontrola techniczna i komunikacja.

1) Traktuj wydarzenia offboardingowe jako wrażliwe i projektuj je z myślą o prywatności

Offboarding nieuchronnie zmienia systemy, ale można ograniczyć wyczerpanie informacji:

  • Ogranicz zmiany w katalogach dostępnych publicznie do momentu nawiązania komunikacji.
  • Unikaj masowego usuwania użytkowników, których konta można łatwo odróżnić.
  • Warto rozważyć opóźnienie o kilka godzin niektórych aktualizacji, które nie są krytyczne dla bezpieczeństwa, aby nie powodowały one sytuacji, w której pracownicy są na bieżąco informowani o zwolnieniach.

Celem nie jest wieczne ukrywanie rzeczywistości. Chodzi o to, by bolesne wydarzenie nie zamieniło się w poszukiwanie skarbów.

2) Dodaj kontrolę dostępu opartą na celu i rejestrowanie

Jeśli wewnętrzne interfejsy API mogą ujawniać zmiany statusu pracowników na dużą skalę, to:

  • Dostęp powinien być ograniczony do ról, które go potrzebują.
  • Eksport hurtowy powinien wymagać uzasadnienia.
  • Zapytania powinny być rejestrowane z uwzględnieniem tożsamości i intencji.
  • Zautomatyzowane sondaże powinny się wyróżniać.

W tym miejscu liczy się podejście oparte na „audycie i odpowiedzialności”: jeśli skrypt zlicza użytkowników i wysyła alerty, powinien on wywołać wykrycie.

3) Miej humanitarny plan komunikacji na wypadek zwolnień

Najważniejszym czynnikiem wpływającym na śledzenie cieni jest niepewność.

Firmy mogą ograniczyć skłonność do gromadzenia danych z wewnętrznych narzędzi, wyraźnie określając tę ​​kwestię:

  • Kiedy pracownicy, których to dotyczy, zostaną o tym poinformowani?
  • Kiedy zespoły zostaną poinformowane?
  • Co można udostępniać i kiedy?
  • Gdzie ludzie powinni szukać zweryfikowanych aktualizacji?

Jeśli kierownictwo zapewni aktualne i konkretne informacje, „potrzeba” tworzenia list zadań do wykonania spada.

4) Zapewnij pracownikom autoryzowany sposób sprawdzania współpracowników

To subtelne, ale ważne. Ludzie są nie tylko ciekawi – próbują koordynować pracę i sprawdzać, co u znajomych.

Prosty, zatwierdzony komunikat o stanie katalogu („to konto nie jest już aktywne”) bez znaczników czasu, lokalizacji lub list mógłby zaspokoić podstawowe potrzeby bez konieczności przeprowadzania masowej rekonstrukcji.

Szerszy trend: zwolnienia jako test wytrzymałościowy bezpieczeństwa informacji

Zwolnienia ujawniają słabe punkty w zarządzaniu, ponieważ powodują:

  • seria wrażliwych wydarzeń,
  • wysoka temperatura emocjonalna,
  • i duża rotacja użytkowników.

Właśnie wtedy można zaobserwować przypadki skrajne: pracownicy korzystający z systemów, improwizujący menedżerowie i wykorzystujący narzędzia w sposób, do którego nikt ich nie przewidywał.

Strony takie jak Layoffs.fyi istnieją, ponieważ ludzie chcą uzyskać niezależny sygnał o skali cięć w branży. Wewnątrz firmy ta sama potrzeba istnieje – z tą różnicą, że sygnały są bardziej bezpośrednie, a stawki osobiste.

Podsumowanie

Zwalnianie inżynierów przez Pinterest za tworzenie skryptów do śledzenia zwolnień nie jest jedynie przejawem zasady „nie bądź wścibski”. To ostrzeżenie, że wewnętrzna obserwacja może przerodzić się w wewnętrzny nadzór w momencie utraty zaufania do organizacji.

Jeśli twoje narzędzia ułatwiają przekształcenie odejścia z pracy w listę zwolnionych współpracowników, ludzie będą to robić – zwłaszcza podczas zwolnień. Rozwiązaniem jest nie tylko karanie osób, które napisały scenariusz, ale także budowanie systemów i praktyk komunikacyjnych, które nie przekształcą odejścia z pracy w wyciek danych i będą traktować status zatrudnienia jako poufną informację.

Źródła

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...
o Polski