WordPress gotowy do wdrożenia propozycji automatycznej aktualizacji starszych witryn do 4,7

Współtwórcy WordPressa z całego świata dołączyli wczoraj do ożywionego spotkania, aby kontynuować dyskusję na temat propozycji automatycznej aktualizacji starych witryn do wersji 4.7 w ramach kontrolowanego wdrażania. Chodzi o to, aby witryny stopniowo aktualizowały się z jednej głównej wersji do następnej (nie wszystkie naraz). Dyskusję poprowadził Andrew Nacin, lider wydania WordPress 3.7, z pomocą Iana Dunna i szefa zespołu ds. bezpieczeństwa Jake'a Spurlocka.

W oparciu o odpowiedzi uczestników podczas spotkania, było kilku dysydentów, którzy nie czują się komfortowo z aktualizacją starych witryn bez wyraźnej zgody właściciela witryny, co jest trudne do uzyskania, gdy e-maile i powiadomienia administracyjne nie dotrą do wszystkich, których to dotyczy.

Większość autorów skłania się ku znalezieniu najlepszej implementacji, aby przejść dalej z propozycją, co zasadniczo stanowi odważną decyzję dla zwykłych użytkowników, którzy mogą nie wiedzieć, że nie korzystają z najnowszej wersji WordPressa, oraz dla tych, którzy porzucili swoje witryny. Właściciele witryn, którzy aktywnie decydują się na wstrzymanie się ze starszymi wersjami, najprawdopodobniej już zrezygnowali z automatycznych aktualizacji, a te decyzje będą respektowane przez system aktualizacji.

Dunn powiedział, że jego celem w dyskusji było „nasłuchiwanie pomysłów i, miejmy nadzieję, zbliżenie się do jakiejś decyzji”. Na początku skupiono się bardziej na marketingu i szczegółach implementacji, niż na kwestii, czy WordPress powinien automatycznie aktualizować witryny do głównych wersji.

„Myślę, że wokół tego potrzebny jest duży impuls marketingowy” — powiedział Spurlock. „Chcemy wyprzedzać wszelkie wiadomości o łamaniu witryn WordPress i być w stanie przedstawić tę aktualizację jako główną korzyść dla milionów aktualizowanych witryn”. Po zachęcie dyrektora wykonawczego WordPress Josepha Haden, chętni do dyskusji na temat procesu wdrażania wycofali się, aby zająć się bardziej centralną kwestią samych automatycznych aktualizacji. Spurlock podsumował trzy opcje, które zespół ds. bezpieczeństwa ma dla starszych witryn:

1. Porzuć aktualizacje zabezpieczeń dla starszych witryn
2. Kontynuuj aktualizacje zabezpieczeń po ogromnych kosztach
3. Ręcznie aktualizuj witryny, pozostawiając starsze witryny bez aktualizacji.

„Warto podkreślić, że ci właściciele witryn mieli już powiadomienia administracyjne od sześciu lat” – powiedział Nacin. „Najstarsze witryny prawdopodobnie otrzymały na północ od 30 e-maili. Sposób, w jaki możemy przekazać nową funkcję (powiedzmy w wersji 5.3 lub 5.4) w celu dodania obsługi automatycznych aktualizacji głównych wersji, może drastycznie różnić się od sposobu, w jaki możemy obsługiwać starą witrynę z wersją 3.7, którą chcielibyśmy przenieść do wersji 3.8 i nowszej”.

Współtwórcy rozważają konsekwencje pozostawienia starszych witryn bez aktualizacji

Główny współtwórca Zebulan Stanphill był jednym z najgłośniejszych przeciwników automatycznej aktualizacji do głównych wersji bez zgody.

„Funkcja automatycznej aktualizacji w wersji 3.7 nie była reklamowana jako zawierająca główne aktualizacje, więc moim zdaniem wydaje się zwodnicze, aby nagle zmienić ją tak, aby to obejmowała” – powiedział Stanphill. „To tak, jakby przejąć większą kontrolę nad witryną, niż właściciel pierwotnie dał WordPressowi. Nie przeszkadza mi to, że automatyczne główne aktualizacje stają się domyślne w nowych wersjach WordPressa, ale stosowanie ich z mocą wsteczną do starych wersji wydaje mi się niewłaściwe”.

Gary Pendergast, pełnoetatowy sponsorowany współtwórca core, odpowiedział, że problemem jest to, że potencjalnie miliony właścicieli witryn nie zobaczą powiadomienia i utkną na starych wersjach, które w końcu staną się niepewne. Stanphill argumentował, że WordPress nie jest odpowiedzialny za aktualizowanie dla nich witryn osób, które nie wyraziły na to zgody.

„Naszym obowiązkiem jest nie budowanie podwalin pod botnet dla znacznej części Internetu” – powiedział Pendergast.

WordPress ma znacznie większy zasięg w sieci niż w 2013 roku, kiedy system automatycznych aktualizacji został wprowadzony w wersji 3.7. Udział platformy w rynku wzrósł do 34,5% z 10 milionów najlepszych witryn w sierpniu 2019 r. Witryny z 3.7 zostały nieformalnie oszacowane na około 2 miliony, ale ostateczna liczba nie została potwierdzona.

„Jeśli nieświadomie damy komuś platformę do czynienia prawdziwego zła, jesteśmy wystarczająco wielcy, że może to mieć konsekwencje” – powiedziała główna współpracowniczka Mary Baum.

Brak wyraźnej zgody i możliwość złamania były dwoma głównymi obawami tych, którzy sprzeciwiali się planowi. Zwolennicy uważają, że można to zrobić bez łamania milionów stron internetowych. Były szef zespołu ds. bezpieczeństwa, Aaron Campbell, podkreślił zalety wielopoziomowego wdrażania aktualizacji:

Mówiąc o rozpoczęciu od 3.7 użytkowników jako bazy testowej (co jest częścią planu zaproponowanego przez Iana), jedną ze wspaniałych rzeczy, które możemy zaoferować użytkownikom, których sami mają trudności, jest powolna aktualizacja z wersji na wersję. Przycisk na desce rozdzielczej witryny 3.7 zaktualizuje witrynę do wersji 5.2, co jest zrozumiałe przerażające. Zaktualizowalibyśmy 3,7->3,8, potem 3,8->3,9, itd., aż do 4.6->4,7. Zaoferuje płynniejszą ścieżkę od 3,7 do 4,7 ORAZ zapewni nam wiele miejsc na ulepszenie procesu po drodze, jeśli zajdzie taka potrzeba.

Myślę, że zwijanie ma pewne zalety. Jednym z nich są zmiany w bazie danych, które będą wprowadzane porcjami tak samo, jak w ciągu ostatnich 6 lat, a nie zbiorczo w jednej aktualizacji. Wygląda na to, że spowodowałoby to również mniej błędów pamięci i limitów czasu.

Jak stwierdził w poprzednich dyskusjach na temat P2, Nacin powtórzył, że głównym planem zespołu zawsze było wprowadzenie automatycznych aktualizacji dla głównych wersji:

Chcę podzielić się odrobiną historii i kontekstu: tylko najnowsza wersja WordPressa jest oczywiście oficjalnie obsługiwana. Automatyczne aktualizacje w tle w wersji 3.7 (październik 2013) całkowicie zmieniły rachunek — po raz pierwszy byliśmy w stanie wysyłać aktualizacje zabezpieczeń do starszych oddziałów. Ale nie ogłosiliśmy ani nie udokumentowaliśmy tych starszych wersji, nie oferowaliśmy ich do regularnego pobierania ani nie udostępnialiśmy na ekranie Pulpit → Aktualizacje. Nie mieliśmy zamiaru – i nadal nie jest – zmieniać naszych często powtarzanych zasad, zgodnie z którymi oficjalnie obsługiwana jest tylko najnowsza wersja WordPressa. Zdaliśmy sobie jednak sprawę, że jeśli budujemy możliwość szybkiego przesyłania poprawek bezpieczeństwa do starszych, nieobsługiwanych witryn, nie będziemy w stanie korzystać z tej funkcji.

Spodziewaliśmy się, że dokonamy szybszych postępów w automatycznych aktualizacjach głównych wydań, poprawiając bezpieczeństwo i odporność tych aktualizacji. Umożliwiłoby nam to zaktualizowanie tych starszych witryn, aż do wersji 3.7, do nowszych wersji WordPressa. Taki był zawsze plan. Po prostu nie spodziewaliśmy się, że dotarcie tam zajmie nam sześć lat.

Ostatecznie celem długoterminowym jest zmiana domyślnego ustawienia głównych aktualizacji na „rezygnację”, gdy już udowodnią stabilność. Propozycja automatycznej aktualizacji starszych wersji do wersji 4.7 byłaby kolejnym krokiem w kierunku stopniowego podążania w tym kierunku. Nacin twierdzi, że starsze witryny „są już włączone ze względu na instalację WordPressa 3.7+”.

W pewnym momencie spotkania dyskusja na temat etyki automatycznego aktualizowania starszych witryn do wersji 4,7 rozpadła się na analogie dotyczące konserwacji samochodów, szczepień, gnijących zwłok i wszystkiego, co autorzy mogli wyciągnąć z realnego świata, aby ich opinie były bardziej powiązane do aktualnego tematu.

„Trudno mówić o „autonomii” witryn, które zostały skutecznie opuszczone” — powiedział Mark Jaquith. „Na przykład, jeśli padniesz trupem na ulicy, społeczeństwo nie pozwoli ci tam zgnić tylko dlatego, że nie zgodziłeś się na pochówek”.

Główny współpracownik John James Jacoby powiedział, że nie jest w pełni zadowolony z dorozumianej zgody na opt-out vs opt-in, ale ostatecznie zgodził się, że to „coś, co musi się wydarzyć”.

„Ale parafrazując Marka z wcześniej, myślę, że wydaje mi się, że WordPress nie powinien czyścić własnych zwłok z sieci, chyba że zawiera big'ol meta-box w Dashboardzie, który mówi „Hej, musieliśmy to zrobić dla ciebie i oto dlaczego” — powiedział Jacoby.

Inni są bardziej przeciwni zmianom plików na serwerach użytkowników przez WordPress, po tym, jak pierwotnie zakomunikowali, że 3.7 wykona tylko automatyczne aktualizacje zabezpieczeń, chyba że zdecydują się na większe aktualizacje.

„Jestem bardzo przeciwny wprowadzaniu bezobsługowej dużej aktualizacji jakiegokolwiek oprogramowania” – powiedział Gabor Javorszky. „WordPress Core nie ma uprawnień do zmiany kodu na moim serwerze bez mojej wyraźnej prośby. Nie przeszkadza mi to, że aktualizuje się dla mniejszych wersji, ponieważ na to się zapisałem i tak domyślnie działa obecny automatyczny aktualizator. Mogę to zmienić, aby zezwolić na główne aktualizacje, i mogę to zmienić, aby w ogóle nie zezwalać na żadne aktualizacje, ale pominięcie tego wyboru przez WP jest złe”.

Michael Panaga twierdził, że użytkownicy byliby bardziej skłonni zrozumieć, że ich stare witryny zostały zhakowane, niż dowiedzieć się, że ich witryny uległy awarii z powodu nieautoryzowanej automatycznej aktualizacji. Przeciwnicy tej propozycji nie wierzą, że WordPress jest odpowiedzialny za zapobieganie atakom na witryny, nawet jeśli miliony witryn zostaną zhakowane. Postrzegają to jako problem użytkownika lub coś, co firmy hostingowe powinny się zająć.

„Rozsądni ludzie mogą i nie będą się z tym zgadzać, ale zgodnie z naszą filozofią nie uważamy, że za zhakowanie ich witryny nie ponosimy wyłącznej odpowiedzialności użytkownika” — powiedział Nacin. „Czujemy też tę odpowiedzialność i zrobimy absolutnie wszystko, co w naszej mocy, aby ich witryna była aktualizowana i korzystali z najnowszej i najlepszej wersji WordPressa”.

Żadna oficjalna decyzja nie została ogłoszona, ale ci, którzy mają uprawnienia do realizacji planu, są mocno zdecydowani i wydają się osiągnęli konsensus podczas wczorajszego spotkania.

„Pod koniec dnia jest tylko kilka osób, które mają możliwość przeforsowania zmiany na serwerze automatycznych aktualizacji, aby zrezygnować z tej opcji zamiast wyrażać zgodę i wydaje się, że ich umysły są zrobione, więc nie ma sensu kontynuacja P2 [dyskusje] może równie dobrze przejść do fazy implementacji i spróbować zminimalizować zniszczenia” – powiedział deweloper WordPressa Earle Davies.

Nacin podziękował współpracownikom za udział w dyskusji i powiedział, że w nadchodzących dniach zostaną opublikowane posty uzupełniające i prawdopodobnie mapa drogowa, która będzie stanowić podstawę do opracowania w nadchodzących dniach, dokumentującą poprzednie decyzje z 2007 roku.

„Naprawdę cieszę się, że wszyscy pojawiliście się, aby porozmawiać na ten temat” – powiedział Nacin. „Nawet po 10 latach jestem pod ogromnym wrażeniem społeczności WordPressa i tego, jak bardzo dba o swoich użytkowników. Sieć na to zasługuje”.