Pokoyo — Polityka prywatności

Obowiązuje od 19 sierpnia 2026 · dotyczy aplikacji Android com.tr0lczyk.pensjonat, panelu właściciela w przeglądarce oraz publicznego portalu gościa pod adresem /g/…

English version →

Pokoyo tworzy Mateusz Olczyk, niezależny deweloper z Polski. Kontakt: matt.olczyk@gmail.com.

W skrócie. Pokoyo to narzędzie pracy dla małych obiektów noclegowych: organizuje sprzątanie, grafik sauny i jacuzzi oraz prostą stronę informacyjną dla gości. Nie ma w nim reklam, nie sprzedajemy danych i nikogo nie profilujemy.

Tak, przetwarzamy dane gości — dokładnie tyle, ile gość sam wpisze w formularzu prośby o rezerwację (imię, wybrany pokój, opcjonalna uwaga) plus techniczne znaczniki chroniące formularz przed spamem. Opisujemy to szczegółowo w sekcji 5. Danych meldunkowych, dokumentów, numerów kart ani płatności nie obsługujemy w ogóle.

Bazę, zdjęcia i funkcje serwerowe trzymamy w Unii Europejskiej, w regionie europe-central2 (Warszawa). Trzy rzeczy Google prowadzi poza tym regionem i mówimy o nich wprost w sekcji 10: powiadomienia push, logowanie do panelu oraz techniczne logi serwera. Aplikacja Android zbiera też podstawową telemetrię (statystyki użycia i raporty awarii) — jest ona włączona domyślnie, o czym piszemy wprost w sekcji 8.

1. Czego dotyczy ta polityka

Pokoyo składa się z trzech osobnych powierzchni i ta polityka opisuje wszystkie trzy:

Aplikacja Android dla personelu (com.tr0lczyk.pensjonat) — zadania sprzątania, checklisty, zdjęcia pokoi, zgłoszenia usterek.
Panel właściciela w przeglądarce — konfiguracja obiektu, kartoteka personelu, grafik sauny/jacuzzi/rowerów, kalendarze rezerwacji, treść portalu gościa.
Publiczny portal gościa pod adresem /g/{nazwa-obiektu} — strona bez logowania, którą gość otwiera z kodu QR lub linku od obiektu. To jedyne miejsce, w którym dane wpisuje gość, a nie personel.

2. Role: kto za co odpowiada

Pokoyo jest narzędziem typu B2B: my dostarczamy oprogramowanie, a decyzje o tym, jakie dane i po co trafiają do systemu, podejmuje obiekt noclegowy. Dlatego:

Właściciel obiektu jest administratorem danych osobowych swojego personelu i swoich gości. To on zakłada kartotekę personelu, włącza (albo nie) portal gościa, decyduje, jakie pola zbiera formularz prośby o rezerwację, i on ogląda te dane w panelu.
My (deweloper Pokoyo) jesteśmy w tym zakresie podmiotem przetwarzającym (procesorem): przechowujemy i przetwarzamy te dane wyłącznie po to, żeby aplikacja działała, na polecenie właściciela obiektu. Nie używamy danych personelu ani gości do własnych celów.
Administratorem jesteśmy my wyłącznie dla danych konta właściciela (adres e-mail, identyfikator konta) oraz dla telemetrii aplikacji Android (sekcja 8).

Podstawy prawnej dla danych gości i personelu nie ustalamy my — robi to właściciel obiektu jako administrator, bo to on zna kontekst (umowa z gościem, obowiązki obiektu, uzasadniony interes). My przetwarzamy te dane wyłącznie na jego polecenie i w zakresie opisanym w tej polityce.

Jesteś gościem albo członkiem personelu i chcesz dostęp do swoich danych, ich sprostowanie lub usunięcie? Zwróć się w pierwszej kolejności do obiektu, w którym nocujesz lub pracujesz — to on jest administratorem. Możesz też napisać do nas, a my przekażemy sprawę obiektowi i pomożemy ją wykonać technicznie.

3. Konta i logowanie

Personel (aplikacja Android): nie zakłada kont. Telefon otrzymuje anonimowe konto techniczne (losowy identyfikator Firebase Authentication) powiązane z obiektem po wpisaniu 6-znakowego kodu zaproszenia. Nie zbieramy od personelu e-maili, haseł ani numerów telefonu. Nazwę wyświetlaną („Ania", „pokojówka 1") wpisuje właściciel w panelu — to on decyduje, czy jest to imię, pseudonim czy numer.
Właściciel (panel www): loguje się adresem e-mail i hasłem albo kontem Google. Przechowujemy adres e-mail i identyfikator konta; hasła obsługuje Firebase Authentication (Google) — my ich nie widzimy.
Gość (portal): nie zakłada konta i nie loguje się w ogóle.

4. Dane obiektu i personelu

Kategoria	Co dokładnie	Po co
Dane obiektu	Nazwa obiektu, pokoje i przestrzenie (sauna, jacuzzi, rowery), zadania sprzątania, szablony i stany checklist, zgłoszenia usterek, kody zaproszeń, treść portalu gościa wpisana przez właściciela.	Podstawowa funkcja: organizacja i rozliczanie sprzątania oraz grafik wellness.
Kartoteka personelu	Nazwa wyświetlana członka personelu, powiązanie z kontem technicznym, przypisania do zadań, ślad kto i kiedy odhaczył pozycję checklisty, komentarz właściciela do poprawki.	Żeby było wiadomo, kto sprząta który pokój i do kogo wysłać powiadomienie.
Zdjęcia pokoi	Zdjęcia robione przez personel w ramach checklisty lub zgłoszenia usterki (Firebase Storage). Prosimy personel, żeby zdjęcia pokazywały pokój, nie ludzi.	Potwierdzenie wykonania sprzątania i dokumentacja usterek dla właściciela.
Rezerwacje wellness wpisane w panelu	Opis gościa wpisany ręcznie przez właściciela (zwykle numer pokoju lub nazwisko), godzina, cena, informacja o rozliczeniu.	Grafik sauny/jacuzzi i rozliczenie z gościem. Widzi to wyłącznie właściciel.
Powiadomienia push	Tokeny urządzeń (Firebase Cloud Messaging) zapisane w profilu użytkownika; nieaktualne tokeny są usuwane automatycznie.	Powiadomienia o nowych zadaniach, poprawkach, usterkach i prośbach gości.
Ustawienia	Rola użytkownika, powiązanie z obiektem, wybrany język, preferencje powiadomień. Na telefonie personelu dodatkowo: nazwa wyświetlana i motyw, w pamięci aplikacji.	Poprawne działanie uprawnień i interfejsu.

Kto to widzi. Sprzątaczka widzi wyłącznie zadania, checklisty, usterki i zdjęcia swojego obiektu oraz własną kartotekę. Nie widzi kartoteki reszty personelu, kalendarzy rezerwacji, grafiku wellness ani żadnych danych gości. Dostęp znika natychmiast po dezaktywacji w panelu.

5. Portal gościa — co zbieramy od gościa

Portal gościa to publiczna strona bez logowania. Właściciel może ją włączyć lub zostawić wyłączoną; domyślnie jest wyłączona. Strona ma znacznik noindex, więc nie trafia do wyszukiwarek — jest dostępna dla każdego, kto zna jej adres.

5.1. Co gość sam wpisuje

Wyłącznie w jednym miejscu: w formularzu prośby o rezerwację sauny, jacuzzi lub roweru. Gość podaje:

imię (pole tekstowe, do 80 znaków — może wpisać samo imię, inicjały, cokolwiek pozwoli recepcji go rozpoznać);
swój pokój, wybrany z listy pokoi obiektu;
uwagę — opcjonalne pole tekstowe do 500 znaków (np. „przyjdziemy we dwoje"). Jest wolne, więc gość może wpisać w nie, co zechce; prosimy, żeby nie umieszczać tam danych wrażliwych.

Do tego zapisujemy kontekst prośby: jakiej przestrzeni dotyczy, datę i godzinę, status (oczekująca / zatwierdzona / odrzucona / wygasła) oraz moment wysłania. Nie pytamy o nazwisko, e-mail, telefon, adres, numer dokumentu ani o płatność i nie mamy pól, w które można by je wpisać.

Te dane nie zostają na zawsze: 90 dni po terminie, którego prośba dotyczyła, imię, uwaga i oba znaczniki techniczne z punktu 5.2 są automatycznie i trwale czyszczone (szczegóły w punkcie 11).

5.2. Znaczniki techniczne przeciw spamowi

Formularz jest publiczny, więc bez zabezpieczeń zalałby właściciela śmieciami. Razem z prośbą zapisujemy dwie rzeczy, których gość nie wpisuje:

Skrót adresu IP — surowego adresu IP nie zapisujemy. Liczymy z niego skrót SHA-256 i przechowujemy pierwsze 24 znaki. Służy wyłącznie do limitu „maksymalnie 5 próśb na dobę". Mówimy wprost: jest to pseudonim, a nie anonimizacja — skrót jest powiązany z konkretnym adresem IP i nie należy go traktować jak danych całkowicie nieosobowych.

Żeby to zdanie było prawdziwe także o infrastrukturze, a nie tylko o bazie: adres IP gościa musi oczywiście dotrzeć do serwera, bo inaczej nie dałoby się odesłać odpowiedzi — ale nie zostaje po nim żaden zapis. Do 18 sierpnia 2026 techniczny log żądań HTTP naszej funkcji portalu przechowywał surowy adres IP i pełny opis przeglądarki (User-Agent) przez 30 dni. Od 19 sierpnia 2026 ten log w ogóle nie powstaje — jest odfiltrowany zanim trafi gdziekolwiek. Sprawdziliśmy to pomiarem: żądanie wysłane po zmianie nie zostawiło ani jednego wpisu, podczas gdy identyczne żądanie do innej funkcji (używanej wyłącznie przez właściciela) zapisało się normalnie.
Identyfikator urządzenia — losowy identyfikator (UUID) generowany w przeglądarce gościa i zapisany w jej pamięci lokalnej pod kluczem pokoyo-portal-device. Nie zawiera niczego o gościu ani o telefonie; służy do tego samego limitu dziennego. W trybie prywatnym przeglądarki nie powstaje.

W pamięci lokalnej przeglądarki gościa zapisujemy też, które prośby zostały już wysłane (klucz pokoyo-portal-sent-…, kasowany po dwóch dniach) oraz wybrany język (pokoyo-portal-lang). To nie są ciasteczka śledzące, nie wychodzą poza przeglądarkę gościa poza wysłaniem samej prośby i nie służą do reklam.

5.3. Co portal pokazuje publicznie

Portal wyświetla: nazwę obiektu, telefon do recepcji, treści i zdjęcia wpisane przez właściciela, mapę okolicy, listę nazw pokoi (potrzebną do wyboru w formularzu) oraz grafik sauny/jacuzzi/rowerów jako wolne albo zajęte.

Portal nigdy nie pokazuje: imion ani uwag innych gości, kto zajmuje który pokój, statusów sprzątania, cen, zdjęć pokoi z checklist ani czegokolwiek z części wewnętrznej. Gość nie może też odczytać własnej wysłanej prośby — trafia ona wyłącznie do właściciela.

Zdjęcia, które właściciel wstawi do portalu (np. widok tarasu, menu), są z natury rzeczy publicznie dostępne pod swoim adresem — tak jak każde zdjęcie na stronie www.

5.4. Kto widzi prośby gości

Wyłącznie właściciel obiektu, w swoim panelu. Personel sprzątający nie ma do nich dostępu na poziomie reguł bezpieczeństwa bazy — nie chodzi o ukryty ekran, tylko o brak uprawnień. Treść prośby (imię i godzina) trafia dodatkowo do powiadomienia push wysyłanego właścicielowi, więc przechodzi przez infrastrukturę powiadomień Google/przeglądarki, tak jak każde powiadomienie web push.

5.5. Mapa

Jeśli właściciel doda do portalu sekcję z mapą, kafelki mapy pobiera przeglądarka gościa bezpośrednio z serwerów OpenStreetMap. Oznacza to, że adres IP gościa i to, który fragment mapy ogląda, trafiają do OpenStreetMap Foundation — my tego nie pośredniczymy i nie zapisujemy. Bez sekcji z mapą żadne zapytanie tam nie idzie.

6. Kalendarze rezerwacji (Booking, Airbnb, Google Calendar)

Właściciel może podać w panelu adres kalendarza iCal z serwisu rezerwacyjnego, żeby wyjazd gościa sam zamieniał się w zadanie sprzątania. Z takiego kalendarza pobieramy i przechowujemy wyłącznie: identyfikator techniczny wydarzenia oraz datę przyjazdu i wyjazdu.

Imion i nazwisk gości z tych kalendarzy nie zapisujemy. Opis wydarzenia jest wprawdzie odczytywany (żeby rozpoznać, czy to rezerwacja, czy blokada terminu), ale nie trafia do bazy. Adres kalendarza jest traktowany jak sekret: widzi go tylko właściciel i nie umieszczamy go w powiadomieniach ani w e-mailach alarmowych.

7. Automatyczne tłumaczenie treści portalu

Portal gościa działa w czterech językach: polskim, angielskim, ukraińskim i rosyjskim. Treści wpisane przez właściciela tłumaczymy automatycznie przez Google Cloud Translation. Do tłumaczenia wysyłamy wyłącznie teksty napisane przez właściciela (tytuły sekcji, opisy atrakcji) i tylko te, które się zmieniły. Imię gościa i jego uwaga nigdy nie są nikomu wysyłane do tłumaczenia. Pozycje checklist personelu również nie są tłumaczone.

Od 19 sierpnia 2026 tłumaczenie odbywa się na europejskim (regionalnym) punkcie dostępowym Google Cloud Translation, w regionie europe-west1. Wcześniej używaliśmy punktu globalnego, przy którym Google mógł obsłużyć żądanie w dowolnym regionie świata — było to jedyne miejsce w całym naszym backendzie nieprzypięte do Europy. Teraz teksty wysyłane do tłumaczenia nie opuszczają Unii.

8. Telemetria aplikacji Android

Aplikacja Android korzysta z Google Firebase Analytics (statystyki użycia) oraz Firebase Crashlytics (raporty awarii). Zbierane są automatyczne zdarzenia Firebase (uruchomienie aplikacji, otwarte ekrany), model urządzenia, wersja systemu i aplikacji oraz — przy awarii — stan aplikacji w chwili błędu. Nie wysyłamy do telemetrii żadnych własnych zdarzeń z treścią zadań, nazwami pokoi, imionami ani danymi gości.

Ważne: telemetria jest włączona domyślnie. Aplikacja jest narzędziem B2B bez reklam — dane telemetryczne służą wyłącznie diagnozowaniu błędów i rozwojowi produktu, nigdy do reklam ani profilowania marketingowego. Aplikacja nie wyświetla okna zgody na telemetrię; podstawą przetwarzania jest nasz prawnie uzasadniony interes (art. 6 ust. 1 lit. f RODO), a administratorem tych danych jesteśmy my. Jeśli nie akceptujesz telemetrii, napisz do nas — a do tego czasu jedyną pełną alternatywą jest niekorzystanie z aplikacji.

Biblioteka Firebase Analytics dokłada do aplikacji systemowe uprawnienie do odczytu identyfikatora reklamowego (AD_ID). Piszemy o tym wprost, bo widać je w sklepie: aplikacja nie wyświetla reklam, nie współpracuje z żadną siecią reklamową i nie używa tego identyfikatora do reklam ani do profilowania. Panel w przeglądarce i portal gościa nie mają żadnej analityki — ani Google Analytics, ani innej.

9. Usługi, z których korzystamy

Usługa	Do czego	Co do niej trafia
Google Firebase / Google Cloud (Authentication, Firestore, Storage, Cloud Functions, Hosting)	Cały backend: baza, pliki, logowanie, funkcje serwerowe.	Wszystko, co opisano wyżej. Region `europe-central2` (Warszawa).
Firebase Cloud Messaging i systemy powiadomień przeglądarek	Powiadomienia push do właściciela i personelu.	Treść powiadomienia — w tym imię gościa przy nowej prośbie o rezerwację i komentarz właściciela przy poprawce.
Google Cloud Translation	Tłumaczenie treści portalu na EN/UA/RU.	Wyłącznie teksty napisane przez właściciela (sekcja 7). Europejski punkt dostępowy, region `europe-west1`.
Google Cloud Logging	Techniczne logi działania serwera — do znajdowania awarii.	Komunikaty diagnostyczne pisane przez nas: identyfikatory obiektu, prośby, pokoju i zadania, daty, liczniki oraz treść błędów. Bez imienia gościa, bez jego uwagi, bez adresu IP i bez User-Agenta (sekcja 10). Przechowywane 30 dni.
Resend (region Irlandia, UE)	Jeden e-mail: alarm do właściciela, gdy kalendarz rezerwacji przestał się pobierać.	Adres e-mail właściciela, nazwa obiektu, nazwa kalendarza, treść błędu, link do panelu. Bez adresu kalendarza i bez danych gości.
Serwis rezerwacyjny właściciela (Booking, Airbnb, Google Calendar)	Pobranie kalendarza iCal.	Zapytanie wychodzi od nas do adresu podanego przez właściciela; nie wysyłamy tam żadnych danych z Pokoyo.
OpenStreetMap	Kafelki mapy na portalu gościa, jeśli właściciel doda sekcję z mapą.	Adres IP przeglądarki gościa (sekcja 5.5).

To pełna lista. Poza tymi usługami nie przekazujemy danych nikomu — żadnych sieci reklamowych, brokerów danych, narzędzi marketingowych czy analitycznych stron trzecich.

10. Gdzie dane są przechowywane

Backend to Google Firebase w ramach Google Cloud. Dane obiektu, zdjęcia i funkcje serwerowe działają w regionie europe-central2 (Warszawa). Tłumaczenia portalu idą przez europejski punkt dostępowy Cloud Translation (europe-west1). Alarmy e-mail wychodzą przez Resend z regionu Irlandia (eu-west-1). Google LLC i Resend działają jako nasi podpowierzający; transfer danych regulują standardowe klauzule umowne tych dostawców.

Czego Google nie pozwala przypiąć do Europy — piszemy to wprost, zamiast obiecywać więcej, niż da się dotrzymać:

Powiadomienia push (Firebase Cloud Messaging) chodzą po infrastrukturze globalnej. Google nie oferuje tu wyboru regionu. Treść powiadomienia o nowej prośbie zawiera imię gościa — to jedyne dane gościa, które opuszczają Europę.
Logowanie do panelu (Firebase Authentication) to również usługa globalna, bez wyboru regionu. Dotyczy właściciela i personelu, nie gości.
Techniczne logi serwera (Cloud Logging) trafiają do standardowego magazynu o lokalizacji global — Google nie gwarantuje dla niego regionu. Trzymamy je 30 dni i używamy wyłącznie do znajdowania awarii. Od 19 sierpnia 2026 nie ma w nich żadnych danych gościa: log żądań portalu (jedyne miejsce z surowym adresem IP i User-Agentem) w ogóle nie powstaje, a nasze własne komunikaty przejrzeliśmy linia po linii i usunęliśmy z nich to, co mogło nieść dane osobowe — m.in. cytat wadliwej linii kalendarza pobieranego z serwisu rezerwacyjnego, w której mogło znaleźć się imię lub telefon gościa.

11. Jak długo przechowujemy dane

Dane	Jak długo
Zdjęcia pokoi z checklist i usterek	12 miesięcy od przesłania — potem plik kasuje automat (raz na dobę). W panelu w miejscu zdjęcia pojawia się „zdjęcie usunięte po roku"; historia pracy zostaje.
Prośby gości o rezerwację (imię, uwaga, skrót IP, identyfikator urządzenia)	90 dni od terminu, którego prośba dotyczyła — potem automat (ten sam, raz na dobę) trwale czyści imię, uwagę, skrót IP i identyfikator urządzenia. Sam wpis zostaje bez tych danych: właściciel dalej widzi, że o dany slot ktoś prosił, z którego pokoju i jak się to skończyło, ale nie widzi już, kto to był. Dzieje się to automatycznie, niezależnie od statusu prośby (oczekująca, zatwierdzona, odrzucona, wygasła) i nie wymaga działania właściciela.
Rezerwacje wellness wpisane w panelu	Nazwisko lub notatka o gościu dopisana do rezerwacji: 90 dni od terminu sesji — potem czyści ją ten sam automat (dotyczy to również nazwiska przepisanego z zatwierdzonej prośby gościa). Sama rezerwacja (przestrzeń, pokój, godzina, cena, rozliczenie) zostaje do usunięcia przez właściciela; anulowanie zmienia status, nie kasuje wpisu.
Wydarzenia z kalendarzy rezerwacyjnych	Do zniknięcia z kalendarza źródłowego — wtedy usuwamy je przy najbliższej synchronizacji.
Dane obiektu (pokoje, zadania, checklisty, kartoteka personelu)	Przez czas korzystania z aplikacji przez obiekt; usuwane na wniosek właściciela.
Konta techniczne personelu	Do odpięcia od kartoteki (np. przy zmianie telefonu) lub usunięcia z kartoteki.
Tokeny powiadomień push	Nieaktualne usuwane automatycznie po nieudanej wysyłce.
Zdjęcia czekające na wysyłkę w telefonie personelu	Po wysłaniu plik znika z telefonu od razu; nieudane i zakończone wpisy kolejki są czyszczone po 7 dniach.
Pamięć lokalna przeglądarki gościa	Lista wysłanych próśb — 2 dni. Identyfikator urządzenia i wybrany język zostają do czasu wyczyszczenia danych przeglądarki przez gościa.
Telemetria (Analytics, Crashlytics)	Zgodnie z okresami retencji Firebase (maksymalnie kilkanaście miesięcy).

12. Uprawnienia aplikacji Android

Uprawnienie	Po co
`INTERNET`, `ACCESS_NETWORK_STATE`	Synchronizacja zadań, checklist i zdjęć z backendem.
`POST_NOTIFICATIONS`	Powiadomienia o nowych zadaniach i poprawkach (Android 13+; pytamy o zgodę systemową, odmowa nie blokuje pracy).
`FOREGROUND_SERVICE`, `WAKE_LOCK`, `RECEIVE_BOOT_COMPLETED`, `VIBRATE`	Dokończenie wysyłki zdjęć w tle i sygnał powiadomienia. Dokładane przez biblioteki Google (WorkManager, FCM).
`AD_ID` i pokrewne	Dokładane przez bibliotekę Firebase Analytics. Nie używamy identyfikatora reklamowego — patrz sekcja 8.

Aplikacja nie ma uprawnienia do aparatu ani do lokalizacji. Zdjęcia robione są systemową aplikacją aparatu; zdjęcie trafia najpierw do prywatnego katalogu aplikacji, a po udanym przesłaniu na serwer jest powiązane z zadaniem i kasowane z telefonu.

13. Czego nie robimy

Nie sprzedajemy danych — żadnych, nikomu, w żadnej formie.
Nie wyświetlamy reklam i nie współpracujemy z sieciami reklamowymi.
Nie profilujemy gości ani personelu i nie podejmujemy wobec nich zautomatyzowanych decyzji.
Nie przekazujemy danych poza usługi wymienione w sekcji 9.
Nie zbieramy lokalizacji, kontaktów ani zawartości telefonu.
Nie obsługujemy meldunku, dokumentów tożsamości, danych kart ani płatności.
Nie wysyłamy gościom żadnych e-maili ani SMS-ów; jedyny e-mail, jaki Pokoyo wysyła, to alarm techniczny do właściciela.
Nie używamy ciasteczek śledzących ani analityki na stronie portalu i w panelu.

14. Bezpieczeństwo

Dostęp do danych jest ograniczony regułami po stronie serwera, nie tylko ukrywaniem ekranów: gość może odczytać wyłącznie publiczną treść portalu, sprzątaczka wyłącznie zadania swojego obiektu i własną kartotekę, a prośby gości i grafik wellness — tylko właściciel. Połączenia idą po HTTPS. Jako deweloper mamy techniczny dostęp administracyjny do backendu; korzystamy z niego wyłącznie do utrzymania i diagnostyki.

15. Twoje prawa

Zgodnie z RODO masz prawo do dostępu do swoich danych, ich sprostowania, usunięcia, ograniczenia przetwarzania, przenoszenia oraz sprzeciwu wobec przetwarzania opartego na prawnie uzasadnionym interesie. W sprawach danych gości i personelu właściwym adresatem wniosku jest właściciel obiektu (administrator) — my wykonamy to, o co poprosi. W sprawach konta właściciela i telemetrii adresatem jesteśmy my. Masz też prawo wnieść skargę do Prezesa Urzędu Ochrony Danych Osobowych (PUODO).

16. Dzieci

Aplikacja i panel są narzędziami do pracy i nie są przeznaczone dla dzieci poniżej 16 lat. Świadomie nie zbieramy danych dzieci. Portal gościa nie pyta o wiek — prosimy, żeby prośby o rezerwację wysyłała osoba dorosła z rezerwacji.

17. Zmiany tej polityki

O istotnych zmianach poinformujemy w aplikacji lub na tej stronie, aktualizując datę „obowiązuje od". Aktualna wersja zawsze znajduje się pod adresem https://tr0lczyk.github.io/pensjonat/privacy/.