„Pinterest“ atleido inžinierius, kurie stebėjo atleidimus iš darbo „Slack“ platformoje – ką tai sako apie privatumą, pasitikėjimą ir vidinę telemetriją

/Bendra/ Autorius

Pranešama, kad „Pinterest“ atleido du inžinierius, parašiusius scenarijus, skirtus nustatyti, kurie bendradarbiai atleidžiami iš vidinių įrankių atleidimo iš darbo metu, o vėliau šį sąrašą pasidalijo plačiau. Iš pirmo žvilgsnio tai yra darbovietės drama. Po to tai neįprastai aiškus atvejo tyrimas, kaip iš tikrųjų veikia šiuolaikinės įmonės: tapatybės sistemos kaip tiesos šaltinis, pokalbių platformos kaip de facto organizacinės schemos ir „vidiniai duomenys“, kurie techniškai prieinami dar gerokai prieš tai, kai jie tampa socialiai priimtini.

Šis incidentas svarbus ne tik „Pinterest“, nes beveik kiekvienoje technologijų įmonėje egzistuoja tie patys elementai: centralizuota tapatybė, „Slack“ arba „Teams“, HR sistemos ir ilgas vidinių ataskaitų suvestinių bei API rinkinys. Kai laikai ramūs, niekas per daug negalvoja apie ribą tarp stebimumo ir priežiūros. Kai įvyksta atleidimai iš darbo, ši riba išryškėja.

Šiame aiškinamajame dokumente apžvelgsime, kas greičiausiai įvyko, kodėl kyla pagunda atlikti tokio pobūdžio stebėjimą, kur jis peržengia etikos ir politikos ribas ir ką organizacijos gali padaryti, kad sumažintų žalą privatumui ir norą rinkti šešėlinę informaciją.

Kas nutiko (ir ką čia tikriausiai reiškia „scenarijus“)

BBC teigimu, „Pinterest“ teigė, kad „du inžinieriai parašė pasirinktinius scenarijus, netinkamai pasiekdami konfidencialią įmonės informaciją, kad nustatytų visų atleistų darbuotojų buvimo vietą ir vardus, o vėliau jais pasidalijo plačiau“, vadindami tai politikos pažeidimu ir privatumo problema paveiktiems darbuotojams. Ataskaitoje taip pat aprašomas mechanizmas, kuriuo stebima, ar darbuotojų vardai nėra pašalinami arba deaktyvuojami vidinės komunikacijos įrankyje, „pvz., „Slack“.

Daugelyje įmonių „Slack“ (ar panaši) sistema yra tiesiogiai susieta su tapatybės teikėju („Okta“, „Azure AD“, „Google Workspace“ ir kt.). Išjungus paskyrą, įvyksta kaskadinis procesas: prieigos žetonai nustoja galioti, grupės pasikeičia ir vartotojas nustoja būti rodomas tam tikrose katalogų paieškose, kanaluose ir integracijose. Jei turite API prieigą (net ir tik skaitymui), dažnai galite nustatyti, kas buvo nutrauktas, tiesiog aptikdami būsenos pokyčius:

  • Vartotojas dingsta iš „aktyvių vartotojų“ sąrašo.
  • Vartotojo profilis tampa deaktyvuotas.
  • Robotas nebegali jiems siųsti asmeninių žinučių.
  • Jų narystė keičiasi skirtinguose kanaluose arba vartotojų grupėse.

Šiame kontekste „scenarijus“ nebūtinai turi būti sudėtingas. Tai gali būti kelios dešimtys kodo eilučių, kurios apklausia API, lygina vakarykštį vartotojų sąrašą su šiandieniniu ir siunčia įspėjimą. Grynai techniniu požiūriu tai tas pats šablonas, kurį inžinieriai naudoja teisėtoms operacinėms užduotims: dviejų momentinių kopijų lyginimas, siekiant aptikti pokyčius.

Skirtumas yra tas, kas aptinkama (žmonės), kodėl tai aptinkama (atleidimai iš darbo) ir kur pateikiami rezultatai (plačiai bendrinami).

Kodėl darbuotojai tai daro atleidimų metu

Yra nemaloni tiesa apie atleidimus iš darbo: žmonės paprastai sužino apie įvykio eigą per pašalinius kanalus, dar prieš vadovybei ką nors paaiškinant. Kartais taip yra todėl, kad vadovybė dar negali pasidalyti detalėmis. Kartais taip yra todėl, kad „mes vis dar deriname detales“ yra eufemizmas, reiškiantis „mes nenorime sakyti“.

Taigi darbuotojai griebiasi bet kokių egzistuojančių signalų:

  • Draugai staiga tyli.
  • Kalendoriaus kvietimai dingsta.
  • Prieiga prie saugyklų atšaukta.
  • „Slack“ būsena pasikeičia arba asmuo dingsta iš katalogo.

Šių signalų sekimas gali atrodyti kaip savigyna. Žmonės nori žinoti:

  • Ar mano komanda paveikta?
  • Ar mano vadovas buvo atleistas?
  • Ar mano artimiausi bendradarbiai vis dar čia?
  • Ar įmonėje viskas gerai, ar tai didesnė restruktūrizacija?

Ta motyvacija yra žmogiška ir nuspėjama. Tačiau nuspėjamas elgesys vis tiek gali būti žalingas.

Privatumo problema: atleidimo iš darbo statusas yra jautri informacija

Atleidimo iš darbo atvejis nėra vien „darbo smulkmenos“. Tai neskelbtina asmeninė informacija apie asmens užimtumo statusą, dažnai susijusi su išmokomis, imigracija, sveikatos draudimu ir būsimomis darbo perspektyvomis.

Net jei įmonė planuoja viešai paskelbti apie darbuotojų skaičiaus mažinimą, asmenų tapatybė ir jų buvimo vieta paprastai atskleidžiama tik tiems, kuriems tai būtina žinoti:

  • Žmogiškųjų išteklių ir darbo užmokesčio poreikių informacija.
  • IT skyrius turi vykdyti atleidimą iš darbo.
  • Teisiniai poreikiai užtikrinti atitiktį reikalavimams.
  • Vadovai turi tiesiogiai bendrauti su savo komandomis.

Platus vidinis atleistų darbuotojų sąrašo dalijimasis yra kitoks. Jis gali:

  • Pašalinkite paveikto asmens gebėjimą kontroliuoti pasakojimą.
  • Atskleiskite kieno nors buvimo vietą ar priklausomybę komandai.
  • Skatinkite apkalbas ir spėliones („ar tai buvo performansas?“, „ar tai buvo politinis procesas?“).
  • Padidina tikslinio priekabiavimo ar doksingo riziką už įmonės ribų.

„Pinterest“ teiginiai, kad pažeidė buvusių kolegų privatumą, nėra vien viešieji ryšiai. Tai tikra žalos kategorija.

Saugumo problema: prieigos kontrolė nėra tas pats, kas autorizacija

Daugelis vidinių sistemų veikia su apytiksliais leidimais: jei esate inžinierius, galite pateikti užklausą kataloge arba naudoti vidinę API. Tai nereiškia, kad turite leidimą jį naudoti visais tikslais.

Štai kur daugelis organizacijų susiduria su sunkumais. Jos kuria vidinius įrankius, kurie yra:

  • Lengva naudoti,
  • Galingas,
  • Prastai valdomas.

Ir tada jie remiasi politika („nedaryk to“) kaip pagrindiniu apsauginiu turėklu. Kai spaudimas didelis, vien politika paremti turėklai neveikia.

NIST SP 800-53 yra vienas iš standartinių katalogų, kuriuos organizacijos naudoja galvodamos apie kontrolės sistemas, tokias kaip prieigos kontrolė ir auditas. Net ir nepasiklysdami kontrolės ID, pagrindinė idėja čia puikiai tinka: prieiga prie duomenų turėtų būti ribojama, stebima ir siejama su teisėtais verslo tikslais, ypač jautrių informacijos kategorijų atveju.

Kitaip tariant: „techniškai galite tai perskaityti“ niekada neturėtų būti traktuojama kaip „jums viskas gerai, jei skaitote“.

Kultūrinė problema: „Slack“ tapo organizacijos schema

Dauguma įmonių dabar susiduria su dviem lygiagrečiomis realybėmis:

  1. Formali realybė: žmogiškųjų išteklių sistemos, atskaitomybės linijos, oficialūs pranešimai.
  2. Gyvenamoji realybė: „Slack“ kanalai, grupinės asmeninės žinutės, „GitHub“ paminėjimai, budėjimo rotacijos.

Kai formalioje sistemoje kas nors pasikeičia (pavyzdžiui, perleidžiami darbuotojai), tai iš karto sukuria matomus artefaktus realioje sistemoje. Darbuotojai šiuos artefaktus interpretuoja kaip tiesą – kartais stipriau, nei pasitiki vadovybės komunikacija.

Toks neatitikimas sukuria iškreiptą paskatą:

  • Jei vadovybė nepasako, kas vyksta,
  • Jį atkursite iš bet kokių telemetrijos nutekėjimų.

Šis incidentas primena, kad „vidinis skaidrumas“ yra ne tik ryšių strategija – tai ir informacijos saugumo strategija. Jei žmonės jaučia, kad privalo iš nutekintos informacijos sudėlioti realybę, jie tai ir padarys.

Kur inžinieriai peržengė ribą

Net jei suprantate, kodėl kažkas gali sukurti tokį scenarijų, yra bent trys aiškios ribos, kurios peržengiamos:

1) Tikslo apribojimas

Jei duomenų šaltinis yra „konfidenciali įmonės informacija“, tikimasi, kad ji bus naudojama teisėtai verslo funkcijai, o ne atleidimų iš darbo žvalgybai.

NIST privatumo sistemoje pabrėžiamas privatumo rizikos valdymas ir praktikos, apsaugančios asmenis, taikymas. Praktiškai tai reiškia „rinkti ir naudoti duomenis konkretiems, teisėtiems tikslams ir vengti antrinio naudojimo, kuris sukeltų naują žalą“.

Scenarijus, skirtas atleistų kolegų identifikavimui, beveik iš esmės yra antrinis panaudojimas: atleidimo signalai skirti sistemoms apsaugoti ir HR procesams vykdyti, o ne vidiniam atleidimų sąrašui generuoti.

2) Amplifikacija

Žmonės „Slack“ sistemoje dingimus pastebi organiškai – tai aplinkos informacijos nutekėjimas.

Scenarijus aplinkos nutekėjimą paverčia struktūrizuotu duomenų rinkiniu (vardai, vietos, tikėtinos komandos, nutraukimo laikas). Tai yra amplifikacija: žalos potencialas smarkiai padidėja, kai neaiškūs signalai tampa aiškiu sąrašu.

3) Perskirstymas

Platesnis informacijos platinimas yra žingsnis, kurį sunku apginti kaip paprastą smalsumą. Tai sukuria naują jautrios informacijos platinimo kanalą ir įpareigoja autorius atsakyti už netinkamą jos naudojimą.

Ką įmonės gali padaryti: sumažinti nuotėkį, padidinti pasitikėjimą ir sugriežtinti kontrolę.

Klaidingai manoma, kad sprendimas yra „viską užrakinti“. Praktiškai reikia trijų vienas kitą papildančių veiksmų: valdymo, techninės kontrolės ir komunikacijos.

1) Išėjimo iš darbo įvykius traktuokite kaip jautrius ir užtikrinkite privatumą

Atsisakymas neišvengiamai pakeičia sistemas, tačiau galite sumažinti informacijos išeikvojimą:

  • Sumažinkite viešai prieinamų katalogų pakeitimus, kol įvyks ryšys.
  • Venkite masinio vartotojų šalinimo, kurį lengva atskirti.
  • Apsvarstykite galimybę atidėti tam tikrus nesaugumo požiūriu svarbius atnaujinimus valandomis, kad jie neveiktų kaip realaus laiko atleidimų srautas.

Tikslas nėra amžinai slėpti realybę. Tikslas – išvengti, kad skausmingas įvykis nevirstų lobių paieška.

2) Pridėkite tikslinę prieigos kontrolę ir registravimą

Jei vidinės API gali atskleisti darbuotojų statuso pokyčius dideliu mastu, tai:

  • Prieiga turėtų būti suteikta tik tiems vaidmenims, kuriems jos reikia.
  • Didelio masto eksportui turėtų būti reikalingas pagrindimas.
  • Užklausos turėtų būti registruojamos su tapatybe ir ketinimu.
  • Automatinės apklausos turėtų išsiskirti.

Čia svarbus „audito ir atskaitomybės“ požiūris: jei scenarijus išvardija vartotojus ir siunčia įspėjimus, jis turėtų suaktyvinti aptikimą.

3) Turėkite humanišką komunikacijos planą atleidimams iš darbo

Didžiausias šešėlių sekimo veiksnys yra neapibrėžtumas.

Įmonės gali sumažinti impulsą naudoti vidinius įrankius aiškiai išdėstydamos savo poziciją:

  • Kada bus informuoti paveikti darbuotojai?
  • Kada bus informuotos komandos?
  • Kuo ir kada galima dalytis?
  • Kur žmonės turėtų ieškoti patikrintų atnaujinimų?

Jei vadovybė laiku pateikia konkrečią informaciją, „pasidaryk pats“ sąrašų „poreikis“ sumažėja.

4) Suteikite darbuotojams sankcionuotą būdą patikrinti bendradarbius

Tai subtilu, bet svarbu. Žmonės ne tik smalsūs – jie bando koordinuoti darbą ir pasiteirauti apie draugų veiklą.

Paprastas, patvirtintas katalogo būsenos pranešimas („ši paskyra nebeaktyvi“) be laiko žymų, vietos ar sąrašų galėtų patenkinti pagrindinius poreikius, nesuteikdamas galimybės masiškai rekonstruoti.

Platesnė tendencija: atleidimai iš darbo kaip informacijos saugumo streso testas

Atleidimai iš darbo atskleidžia silpnąsias valdymo vietas, nes jie sukuria:

  • jautrių įvykių protrūkis,
  • aukšta emocinė temperatūra,
  • ir daug prieigos praradimo.

Būtent tada ir matome kraštutinius atvejus: darbuotojai naudoja sistemas, vadovai improvizuoja, o įrankiai naudojami taip, kaip niekas nebuvo numatyta.

Tokios svetainės kaip „Layoffs.fyi“ egzistuoja todėl, kad žmonės nori nepriklausomo signalo apie atleidimų mastą pramonėje. Įmonės viduje egzistuoja tas pats poreikis – tik signalai yra tiesioginiai, o rizika – asmeninė.

Esmė

„Pinterest“ sprendimas atleisti inžinierius dėl atleidimų stebėjimo scenarijų kūrimo nėra tiesiog „nesmalsumas“. Tai įspėjimas, kad vidinis stebėjimas gali tapti vidine priežiūra vos tik sumažėja pasitikėjimas organizacija.

Jei jūsų įrankiai leidžia lengvai paversti tapatybės praradimą atleistų bendradarbių sąrašu, žmonės tai darys – ypač atleidimų iš darbo metu. Pataisymas ne tik baudžia scenarijų parašiusius žmones, bet ir sukuria sistemas bei komunikacijos praktikas, kurios nepaverčia atleidimo iš darbo duomenų nutekėjimu ir traktuoja darbo statusą kaip slaptą informaciją, kokia ji ir yra.

Šaltiniai

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...
i Lietuvių kalba