Tom X

Polska, Niemcy czy Francja to wciąż UE, więc jeśli dane są kolokowane na terenie UE i administrator danych osobowych ma siedzibę na terenie UE, to wszystko jest względnie proste dla klienta z UE i podmiotu, który świadczy usługi klientom z UE. Sytuacja komplikuje się, gdy administratorem danych osobowych jest podmiot spoza UE (np. z UK czy USA), ponieważ wtedy dane osobowe formalnie są przesyłane poza obszar UE (np. do państwa, w którym polityka ochrony danych osobowych jest bardziej liberalna niż w UE). Wątek dotyczy państw spoza UE. Istnieją formalnie określone mosty przesyłania danych osobowych USA - UK i USA - UE. Spełnienie tych dodatkowych uwarunkowań nie jest tak proste, jak funkcjonowanie wyłącznie wewnątrz UE, USA czy UK.

@darekm Siedziba podmiotu = siedziba administratora danych osobowych jest bardzo istotna.

@l3szcz IONOS, siteground mają swoje spółki-córki na terenie UK. W przypadku OVH, Hetznera - nie wiem. Warto przeanalizować ich rozwiązania, by nie wyważać otwartych drzwi.

Najprościej: klient UK, serwer UK, operator UK. W przypadku, gdy operator jest spoza UK, trzeba to uwzględnić, bo ma dostęp do danych osobowych. Plus coroczne opłaty ICO (data protection fee).

Prawdopodobnie również certyfikowanych dostawców, jeśli chciałbyś serwować klienteli UK usługi hostowane w USA.

Hostingodawca chcąc obsługiwać klientów danego kraju, musi uwzględniać specyfikę praw danego kraju + obowiązki nakładane w przypadku transferów danych poza ten kraj. Przykładowo, UK wdraża DUAA 2025, który znacząco różni się od Unijnego RODO.

U tego operatora, widełki terminu ważności usługi hostingowej są zawsze precyzyjnie podane na ostatniej FV i one są obligatoryjne dla terminu odnowienia kolejnego abonamentu, nie zaś data pierwotnej rejestracji usługi sprzed 15 lat.

Przyczyn zapadnięcia się pod ziemie może być wiele, od typowo życiowych po typowo biznesowe (nieuregulowane wzajemne zobowiązania finansowe lub niegodzenie się na ich regulację). Brak umów jestem w stanie zrozumieć. Nieumiejętność odnalezienia faktur (zapewne wysłanych e-mailem o ile takowe były wysyłane), skucha z terminem ważności domeny powinny zapalić pomarańczową lampkę. IMO nic tu nie jest oczywiste a szanowna Klientka póki co nie przedstawiła wiarygodnych papierów do przejęcia domeny. Jeśli towarzystwo rozliczało się pod stołem z pominięciem fiskusa, to wejście na drogę prawną może uruchomić pewne niekoniecznie oczekiwane dla Klientki skutki. Dlatego dogadanie się na niwie finansowej z finałem w postaci cesji może okazać się najlepszym i najprostszym rozwiązaniem.

Ukryte dane abonenta mogą wskazywać na brak Działalności Gospodarczej po stronie właściciela domeny (niektórzy tak sobie dorabiają na boku). Wtedy brak FV wydaje się logiczny.

Jeśli korespondencja e-mailowa nie była prowadzona z wykorzystaniem metod gwarantujących jej integralność (np. certyfikaty S/MIME lub umowy/zlecenia w PDF podpisane certyfikatem), to przy braku faktur (o ile wiem, mamy obowiązek przechowywać faktury przez 5 lat) IMO nie są to wystarczające dowody, by posługując się zwykłym e-mailem zablokować lub odebrać komuś domenę (i skąd w ogóle pewność, że słusznie).

"pan Tomasz" =/= "dane niedostępne".

Jeszcze jedno - pracownik CF nie miał prawa udzielić Ci takich informacji: "domena jest w pełni w posiadaniu jak mi przedstawiło CF w mailu jakiegoś informatyka".

Najprościej i najrozsądniej - próba polubownego rozstania się Klientki z Agencją na wzajemnie uzgodnionych warunkach.

Jeśli w bazie WHOIS nie figurują dane Klientki (najprawdopodobniej, bo po co je ukrywać), Klientka nie posiada umowy/cesji praw majątkowych do projektów, to oznacza, że Klientka jedynie dzierżawi branding od Agencji. Może zwrócić się do Agencji z prośbą o cywilizowany proces rozstania się, uzgodnić cenę za cesję praw majątkowych i procedurę cesji domeny. Rozsądna Agencja powinna się zgodzić.

Nie podałeś który podmiot figuruje we wpisie WHOIS domeny: Klientka czy Agencja. Kwestie praw majątkowych do projektów regulują umowy, cesje, zastrzeżenia znaków towarowych.

gsuitedlafirm_online Interesująca lektura.

Jestem ciekaw, na jakim etapie są przygotowania do wdrożenia systemu KSEF w małych i średnich firmach hostingowych: - zamierzacie wystartować z wystawianiem e-faktur od 1 lutego, - czy też ustawowo od 1 kwietnia?

OK, zgoda, posypuję głowę popiołem. Moja nadinterpretacja.

Może nie do końca precyzyjnie się wyraziłem. Jesteśmy w UE a nie w Ameryce. Żadna sprofesjonalizowana firma hostingowa funkcjonująca na terenie UE nie udostępni usługi hostingowej (VPS/Dedyk/hosting) pierwszemu lepszemu nonejmowi prosto z ulicy bez procesu rejestracji, a w istocie tego od nich oczekujesz. To powinno działać w ten sposób, że osoba lub podmiot ubiegający się o materiał do testów, uzyskuje od firmy hostingowej jakiś kod rabatowy uprawniający do 100% zniżki na rejestrację usługi na okres, powiedzmy 48 godzin, następnie rejestruje sobie usługę podając pełne i prawdziwe dane wymagane do rejestracji usługi. Formalnie, wszyscy tu jesteśmy noname. Mimo, że część z was może się prywatnie lub służbowo znać, to nie rozwiązuje obowiązków prawnych i procedur, które mała firemka potrafi sobie po cichu nagiąć, ale większa już tego nie zrobi.

Gdybym nazywał się BardzoPowaznaFirmaHostingowa_pl Sp. z o.o. (AlboJeszczePowazniejsza_pl S.A.), to z całą pewnością nie wysyłałbym parametrów dostępowych usługi hostingowej na maila z domeny, która przedstawia się światu jak poniżej:

Sądziłem, że te stare wersje PHP leżą już odłogiem i nikt się do nich w ogóle nie dotyka.

@kankan Niestety, daty kompilacji niczego nie przesądzają, ponieważ powody kompilacji mogą być różne. Dla wersji 5.x, 7.x i 8.0 są to: marzec, kwiecień i maj 2025.

@ćwierćadmin Chciałbym wiedzieć co zostało załatane, czy za deklaracjami stoją realne i wiarygodne procesy czy radosna twórczość działu mailingu: https://www.php.net/ChangeLog-8.php#PHP_8_0

Z treści oficjalnego mailingu: "Nasz zespół specjalistów samodzielnie opracowuje, a następnie wdraża łatki bezpieczeństwa dla PHP 8.0 i 8.1, zapewniając Twojej witrynie ciągłość działania oraz ochronę przed zagrożeniami." Gdzie zapoznam się z listą oraz dokumentacją waszych autorskich łatek bezpieczeństwa dla PHP 8.0/8.1?

To jest tylko skórka. Larry z wersją 1.6.X, czyli aktualną powinna działać. Może nie działać od wersji 1.7.X. Wciąż jest dostępna w repozytorium skórek. Wersja 1.6.X jeszcze jakiś czas pociągnie w ramach LTS. https://packagist.org/packages/roundcube/larry