Jump to content
Forum Kopalni Wiedzy

Recommended Posts

Gavin Thomas, który w Microsofcie sprawuje funkcję Principal Security Engineering Manager, zasugerował, że ze względów bezpieczeństwa czas porzucić języki C i C++. Thomas argumentuje na blogu Microsoftu, że rezygnacja ze starszych języków na rzecz języków bardziej nowoczesnych pozwoli na wyeliminowanie całej klasy błędów bezpieczeństwa.

Od 2004 roku każdy błąd naprawiony w oprogramowaniu Microsoftu jest przez nas przypisywany do jednej z kategorii. Matt Miller podczas konferencji Blue Hat w 2019 roku zauważył, że większość tych dziur powstaje wskutek działań programistów, którzy przypadkowo wprowadzają do kodu C i C++ błędy związane z zarządzeniem pamięcią. Problem narasta w miarę jak Microsoft tworzy coraz więcej kodu i coraz silniej zwraca się w stronę oprogramowania Open Source. A Microsoft nie jest jedyną firmą, która ma problemy z błędami związanymi  z zarządzaniem pamięcią, pisze Thomas.

W dalszej części swojego wpisu menedżer wymienia liczne zalety C++, ale zauważa, że język ten ma już swoje lata i pod względem bezpieczeństwa czy metod odstaje od nowszych języków. Zamiast wydawać kolejne zalecenia i tworzyć narzędzia do walki z błędami, powinniśmy skupić się przede wszystkim na tym, by programiści nie wprowadzali błędów do kodu, czytamy.

Dlatego też Thomas proponuje porzucenie C++. Jednym z najbardziej obiecujących nowych języków programistycznych zapewniających bezpieczeństwo jest Rust, opracowany oryginalnie przez Mozillę. Jeśli przemysł programistyczny chce dbać o bezpieczeństwo, powinien skupić się na rozwijaniu narzędzi dla developerów, a nie zajmować się tymi wszystkimi pobocznymi sprawami, ideologią czy przestarzałymi metodami i sposobami rozwiązywania problemów.


« powrót do artykułu

Share this post


Link to post
Share on other sites
Posted (edited)

Pytanie dla programistów (głównie), może ktoś się orientuje, na czym polega ta specyfika Rusta jeśli chodzi o zarządzanie pamięcią (w porównaniu np. z Java/C#)? Nie udało mi się znaleźć w necie żadnego krótkiego omówienia, z tego co zrozumiałem, kompilator śledzi przynależność obiektów tworzonych dynamicznie na stercie do zmiennych, na etapie kompilacji jest rozstrzygane, kiedy zwolnić pamięć, możliwe są dwa rodzaje takich jakby referencji do obiektu na stercie, jedna to "na własność" (czyli, gdy zmienna trzymająca "na własność" jakiś kawałek pamięci przestaje być potrzebny, to ta pamięć jest zwalniana), drugi to referencja "pożyczająca od właściciela", która pozwala odwoływać się do obiektu nie zwalniając pamięci (czyli gdy np. jakaś funkcja "pożyczy" sobie obiekt, to może wykonać na nim jakieś  manipulacje, np. odczytać wartość pola, ale nie może zwrócić obiektu jako wynik, a poza tym, tak długo jak obiekt jest "pożyczony" funkcji, żaden kod spoza tej funkcji nie może na nim wykonywać żadnych operacji i to też jest sprawdzane przez kompilator)? I nic więcej (np. żadnych innych rodzajów referencji)?

Czy dobrze zrozumiałem?

P.S. Chyba jednak czegoś nie zrozumiałem, bo przychodzi mi do głowy, że przy takiej interpretacji nie ma przeszkód, żeby kilku "pożyczkobiorców" mogło "pożyczyć" naraz ten sam obiekt od "właściciela", jedyne ograniczenie, że "właściciel" nie może zwolnić pamięci obiektu dopóki ktoś go "pożycza".

Edited by darekp

Share this post


Link to post
Share on other sites

Polecam przeczytać oficjalny manual Rusta. Jest napisany całkiem zwięźle i zrozumiale.

W uproszczeniu jest tak jak napisałeś. Dochodzi jeszcze kwestia tzw lifetime, która jest bardzo ważna przy pożyczaniu. Pożyczona referencja nie może mieć dłuższego lifetime'u niż obiekt, z którego pożycza. Właśnie tego pilnuje kompilator. Czasami nawet trzeba mu w tym pomóc (np jeśli funkcja przyjmuje więcej niż jedną referencję jako argumenty i zwraca jakąś referencję, przez zadeklarowanie lifetime'ów tych referencji). Dodatkowo możesz mieć wiele niemutowalnych referencji jednocześnie, ale tylko jedną mutowalną (przy czym nie możesz mieć jednocześnie niemutowalnych).

Oprócz tego są pewne ułatwienia w bibliotece standardowej, jak np Rc (reference counter), czy jego wersja thread safe czyli Arc (atomic Rc), które przejmują własność obiektu. Można je klonować, co zwiększa licznik referencji trzymanego obiektu i dropowanie kopii powoduje zmniejszenie licznika. Jak licznik dojdzie do zera, to obiekt też jest dropowany.

Są też inne techniki, jak np internal mutability, które trochę obchodzą wewnętrzne zabezpieczenia w sposób w miarę bezpieczny. Obecnie kompilator nie jest jednak w stanie wyłapać błędnego użycia niektórych z tych technik, więc użycie ich jest zalecane tylko jeśli nie da się czegoś zrobić inaczej.

Share this post


Link to post
Share on other sites

Pozwolę sobie zacytować:

Cytat

Rust has all the low-level things you would expect but with restrictions on how they are used. If you really need to go native then you can code using, say, raw pointers, but you have to mark the code as unsafe. In principle, if you don't write any unsafe code, or if you write unsafe code correctly, it is claimed that Rust avoids all of the race hazards inherent in other languages.

Can this be true?

The researchers looked at code in GitHub to find out how Rust is used and what sort of errors actually occurred. The first observation was that there are a lot of unsafe tags. Ironically it is Mozilla's Servo project that used unsafe most often. It seems that Rust is restrictive enough to force developers to turn to unsafe code to get the job done.

Źródło: https://www.i-programmer.info/news/98-languages/12552-is-rust-really-safe.html

Share this post


Link to post
Share on other sites
52 minuty temu, pskosinski napisał:

The researchers looked at code in GitHub to find out how Rust is used and what sort of errors actually occurred. The first observation was that there are a lot of unsafe tags. Ironically it is Mozilla's Servo project that used unsafe most often. It seems that Rust is restrictive enough to force developers to turn to unsafe code to get the job done. 

Trzeba mieć na uwadze, że unsafe jest wymagane do wywołania funkcji zewnętrznych (nie napisanych w języku Rust) przez FFI. Servo korzysta z wielu komponentów napisanych w C++ jak np. silnik JavaScript z Gecko. Stąd nie dziwi mnie, że w tym projekcie często sięgają do bloków `unsafe`.

Dla porównania, w repozytorium Libry ( https://github.com/libra/libra ) na 145 tys. linii kodu blok `unsafe` jest użyty 6 razy.

Share this post


Link to post
Share on other sites
30 minut temu, beczek napisał:

Trzeba mieć na uwadze, że unsafe jest wymagane do wywołania funkcji zewnętrznych (nie napisanych w języku Rust) przez FFI. Servo korzysta z wielu komponentów napisanych w C++ jak np. silnik JavaScript z Gecko. Stąd nie dziwi mnie, że w tym projekcie często sięgają do bloków `unsafe`.

Dla porównania, w repozytorium Libry ( https://github.com/libra/libra ) na 145 tys. linii kodu blok `unsafe` jest użyty 6 razy.

Jeszcze jest używany w kilku miejscach w bibliotece standardowej. Np w std::sync::atomic, czy std::cell, czyli w implementacjach struktur, które używane są do interior mutability.

Pisząc coś, jeżeli potrzebuję odwołać się przez FFI do jakiejś biblioteki, staram się jednak wydzielić obsługę tej biblioteki do oddzielnego crate'a (wszystkie unsafe mam w jednym miejscu). Dzięki temu w kodzie aplikacji czy biblioteki, którą piszę, nigdy nie używam unsafe bezpośrednio. Crate odpowiedzialny za komunikację z zewnętrzną biblioteką łatwiej przetestować niezależnie od pozostałego kodu.

Jeżeli chodzi o Rust, to zacząłem relatywnie niedawno w nim pisać. Wcześniej głównie programowałem w Pythonie, w mniejszym stopniu w C/C++, Lua i Go. Nie wiem, czemu tak długo zwlekałem z nauczeniem się Rusta, bo naprawdę bardzo mi się spodobał. Mam tylko nadzieję, że jego rozwój pójdzie w dobrym kierunku. Trochę rzeczy jeszcze w std brakuje. Sporo jest dostępne tylko w nightly. No ale to w końcu bardzo młody język.

Share this post


Link to post
Share on other sites
18 godzin temu, KopalniaWiedzy.pl napisał:

rezygnacja ze starszych języków na rzecz języków bardziej nowoczesnych pozwoli na wyeliminowanie całej klasy błędów bezpieczeństwa

Tylko, że te błędy to nie wina technologii, tylko czynnika ludzkiego. Od czego dziesiątki lat rozwoju analizatorów kodu, by nie „strzelić sobie w stopę”.

Share this post


Link to post
Share on other sites
Posted (edited)
W dniu 23.07.2019 o 04:46, wilk napisał:

Od czego dziesiątki lat rozwoju analizatorów kodu, by nie „strzelić sobie w stopę”.

Te analizatory kodu nie są tak dobre, jak mogłoby się wydawać. Wygląda na to, że zamiast zaawansowanych analizatorów nieraz lepiej działają proste narzędzia, które "przeskakują" większość analizowanego kodu i wyszukują tylko pewne charakterystyczne konstrukcje w kodzie z dużym prawdopodobieństwem będące błędami: http://lambda-the-ultimate.org/node/5348 (np. odwołanie do x.pole występujące przed sprawdzeniem czy x != null).

Pierwsza myśl może być taka, że jeśli zrobić potężny parser, który bardzo dokładnie przeanalizuje kod programu i wygeneruje dla niego wielkie drzewo z bardzo dużą ilością informacji o szczegółach działania (tak robią duże firmy piszące analizatory), to da się przeprowadzić bardziej dokładną analizę i znaleźć więcej błędów. Ale napisać funkcję, która chodzi po takim wielgachnym drzewie z mnóstwem atrybutów i znajduje błędy to jest "mordęga".

Z drugiej strony, ta sytuacja jest w pewnym sensie "fajna", bo wychodzi na to, że - jeśli chodzi o języki programowania, analizatory kodu itp. - pojedynczy programista (albo niewielki zespół) może konkurować z wielkimi koncernami. I tak chyba jest w praktyce - języki programowania to w większości dzieło pojedynczych ludzi (jeden język -> jeden autor, Lua to chyba wyjątek, jakiś większy zespół z jakiegoś katolickiego uniwersytetu w Brazylii, ale nie jestem pewien), firma JetBrains, która tworzy IDE takie jak IntelliJ, PyCharm, ReSharper, jest o wiele mniejsza od Microsoftu czy Google :) Trzeba "tylko" być zdolnym programistą;)

 

P.S. Zapomniałem napisać, ale jest jest język programowania, który tak dokładnie sprawdza kod na etapie kompilacji, że w praktyce niemal nie występują błędy runtime'u. To Elm (https://elm-lang.org/). Co prawda tylko dla frontendu na przeglądarce (i chyba trudno sobie wyobrazić pisanie np. systemu operacyjnego w ten sposób), ale z drugiej strony chyba fajna sprawa (dopiero się go uczę, nie maiłem okazji jeszcze wykorzystać w praktyce) :)

Edited by darekp

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Similar Content

    • By KopalniaWiedzy.pl
      Facebook zawiesił dziesiątki tysięcy aplikacji. Przyczyną podjęcia takiej decyzji były liczne naruszenia dokonywane przez te aplikacje, w tym nieprawidłowości w dzieleniu się danymi użytkowników.
      Ime Archibong, wiceprezes Facebooka ds. partnerstwa produktowego poinformował, że ruch taki ma związek z wciąż toczącymi się działaniami podjętymi w marcu 2018 roku po tym, jak dwa lata wcześniej okazało się, że firma Cambridge Analytica wykorzystywała dane nawet 87 milionów użytkowników Facebooka do profilowania wyborców w czasie kampanii prezydenckiej w USA.
      Wspomniane na wstępie dziesiątki tysięcy aplikacji zostało stworzonych przez około 400 deweloperów. Większość z nich zawieszono, ale części całkowicie zablokowano dostęp do serwisu społecznościowego. Blokadę nałożono za nieprawidłowe dzielenie się danymi, udostępniania danych bez ich anonimozowania czy też naruszenia zasad serwisu. Jedną z takich aplikacji jest myPersonality, która nieprawidłowo chroniła dane użytkowników, a jej twórcy odmówili przedstawicielom Facebooka przeprowadzenia audytu. Ponadto Facebook podjął działania prawne przeciwko niektórym deweloperom. To firmy takie jak LionMobi czy JediMobi, których aplikacje zarażały użytkowników szkodliwym kodem mającym przynieść im zyski. Pozwano też dwóch Ukraińców, Gleba Sluchewskiego i Andrieja Gorbaczowa, których aplikacja nielegalnie gromiadziła dane oraz południowokoreańską firmę analityczną Rankwave, która odmówiła wspópracy z Facebookiem.
      Dokumenty złożone przed sądem stanowym w Bostonie, które trafiły tam w ramach śledztwa prowadzonego przez prokuratora generalnego stanu Massachusetts, wskazują, że Facebook zawiesił 69 000 aplikacji, z czego 10 000 mogło niewłaściwie posługiać się danymi.

      « powrót do artykułu
    • By KopalniaWiedzy.pl
      Kwestie dotyczące szczepień i szczepionek są ostatnio przedmiotem gorących sporów. Ruchy antyszczepionkowe odnoszą sukcesy, wskutek czego notuje się wzrost zachorowań np. na odrę. W dyskusjach na temat szczepień często padają argumenty o inteligencji czy wykształceniu. Raport Wellcome Trust pozwoli rozstrzygnąć przynajmniej ten aspekt sporu.
      Wellcome Global Monitor 2018 to raport, którego celem było zbadania, jak ludzie odnoszą się do nauki i kwestii związanych ze zdrowiem. To największe tego typu badania na świecie, w ramach których zebrano ankiety od ponad 140 000 osób z ponad 140 krajów świata. Osobny rozdział poświęcono kwestii szczepień.
      Ankietowanych pytano przede wszystkim, czy słyszeli o istnieniu szczepionek. Okazało się, że 89% światowej populacji jest świadomych ich istnienia, nie słyszało o nich 10%, a 1% albo nie wiedział, albo odmówił odpowiedzi. Największą świadomość na temat istnienia szczepionek mają ludzie ze świata zachodniego. W Ameryce Północnej, Australii i Nowej Zelandii 98% mieszkańców wie, że szczepionki istnieją. W Europie Zachodniej odsetek ten wynosi 95%, zaś w Europie Wschodniej 92%. Bardziej świadomi są mieszkańcy Europy Południowej (97%) i Północnej (96%).
      Obraz naszego kręgu kulturowego nie jest już tak różowy, gdy zapytamy o bezpieczeństwo szczepionek. Na pytanie „czy szczepionki są bezpieczne” odpowiedź była silnie zróżnicowana w zależności od regionu. Światowa średnia odpowiedzi „zdecydowanie tak” oraz „tak” wynosiła 79%, natomiast odpowiedzi „nie” i „zdecydowanie nie” udzieliło 7% mieszkańców Ziemi.
      W Ameryce Północnej odsetek odpowiedzi „zdecydowanie tak” i „tak” wyniósł 72%, a 11% uważało, że szczepionki nie są bezpieczne. Dla Australii i Nowej Zelandii odsetek osób twierdzących, że szczepionki są bezpieczne wyniósł 82%, a niebezpieczne – 7%. W Europie Wschodniej jedynie 50% mieszkańców uważa, że szczepionki są bezpieczne, a 17% uznaje je za niebezpieczne. Wśród mieszkańców Europy Zachodniej z opinią, że szczepionki są bezpieczne zgadza się co prawda 59%, ale aż 22% uważa, że są niebezpieczne. Dla Europy Północnej odsetek ten wynosi, odpowiednio, 73% i 10%, a dla Europy Południowej jest to 76% i 10%. Największe zaufanie do szczepionek mają zaś mieszkańcy Azji Południowej, którzy w 95% zgadzają się, że szczepionki są bezpieczne. W Afryce zaufanie do szczepionek waha się od 77 do 85%.
      Nietrudno zauważyć, że największe zaufanie do szczepionek mają mieszkańcy tych krajów, w których szczepionki są najczęściej stosowane i gdzie ratują miliony istnień. Z opinią „szczepionki są bezpieczne” zgadza się najwięcej mieszkańców Bangladeszu i Egiptu (po 97%), następnie Etiopii, Liberii i Tanzanii (po 69%), Indii (95%), Afganistanu i Rwandy (94%) czy Tajlandii, Sierra Leone, Uzebkistanu i Wenezueli (93%). Na pytanie o to, czy szczepionki są efektywne, najczęściej twierdząco odpowiadają mieszkańcy Rwandy (99%), Bangladeszu, Etiopii i Islandii (97%), Afganistanu i Egitpu (96%), Indii, Tadżykistanu i Uzbekistanu (95%), Kambodży, Komorów, Malawi, Tajlandii i Wenezueli (94%) oraz Mjanmy, Norwegii i Sierra Leone (93%). Z kolei z opinią, że szczepienie dzieci jest ważne najczęściej zgadzają się mieszkańcy Egiptu, Etiopii, Nikaragui i Cypru (100%), Bangladeszu, Burundi, Kambodży, Kolumbii, Dominikany, Ekwadoru, Hondurasu, Islandii, Jordanii, Nepalu, Palestyny, Rwandy, Sierra Leone, Tanzanii i Wenezueli (99%). Brazylii, Salwadoru, Iraku, Kenii, Libanu, Liberii, Madagaskaru, Mozambiku, Nigerii, Norwegii, Tadżykistanu, Tajlandii i Ugandy (97%).
      Światowym rekordzistą w odsetku sceptyków jest zaś Francja. Tam aż 33% ankietowanych odpowiedziało, że szczepionki nie są bezpieczne. Na drugim miejscu znajdziemy Gabon (26%), następnie Togo (25%), Rosję (24%), Szwajcarię (22%), Armenię, Austrię, Belgię i Islandię (po 21%) i Burkina Faso oraz Haiti (po 20%). Z opinią, że szczepionki są bezpieczne nie zgadza się 28% mieszkańców Liberii, 19% mieszkańców Francji, a kolejne kraje to Nigeria (16%), Namibia i Peru (15%) oraz Uganda (13%), Armenia, Gabon, Rosja, Togo (po 12), Austria, Indonezja i Holandia (po 11%). Z kolei na pytanie, czy szczepienie dzieci jest ważne, najczęściej przecząco odpowiadali mieszkańcy Armenii i Austrii (12%), Francji (10%), Rosji i Szwajcarii (9%), Azerbejdżanu, Białorusi i Włoch (8%) oraz Bułgarii, Mołdowy i Czarnogóry (7%).
      Niezwykle interesująco wygląda rozkład pod kątem poziomu wykształcenia.
      Opinię, że szczepionki nie są bezpieczne, wyraża 7% ludności świata. Dla osób z wykształceniem co najwyżej podstawowym odsetek ten wynosi 7%, dla osób z wykształceniem średnim jest to 8%, a dla osób z wykształceniem wyższym wzrasta do 10%.
      W Ameryce Północnej odsetek osób twierdzących, że szczepionki nie są bezpieczne, wynosi 11%. Wśród osób z wykształceniem podstawowym jest to 20%, ze średnim – 12%, a z wyższym – 9%. W Europie Zachodniej aż 22% osób twierdzi, że szczepionki nie są bezpieczne. Uważa tak 25% osób z wykształceniem podstawowym, 22% ze średnim i 17% z wyższym. Zupełnie inny obraz widzimy w Europie Wschodniej. Tutaj 17% ankietowanych twierdzi, że szczepionki są niebezpieczne i odsetek ten rośnie wraz z wykształceniem. Dla osób o wykształceniu podstawowym wynosi on 12%, dla tych z wykształceniem średnim jest to 15%, a z wyższym aż 20% i jest to najwyższy odsetek w tej grupie na całym świecie.
      Podobne, zaskakujące dla niektórych, wyniki przynosi badanie ze względu na miejsce zamieszkania.
      Na całym świecie 9% mieszkańców wielkich miast i ich przedmieść twierdzi, że szczepionki są niebezpieczne. Dla małych miasteczek odsetek ten wynosi 7%, a dla wsi spada do 6%. Jeśli spojrzymy na Amerykę Północną, to zauważymy, ze tam 9% wielkich miast uważa szczepionki za niebezpieczne, odsetek ten rośnie do 15% w przypadku miasteczek i spada do 10% wśród mieszkańców wsi. Z kolei w Europie Zachodniej aż 20% mieszkańców wielkich miast twierdzi, że szczepionki nie są bezpieczne. W małych miasteczkach jest to 22%, a na wsiach – 25%. Inne zjawisko widzimy w Europie Wschodniej. Tutaj 19% mieszkańców wielkich miast uważa szczepionki za niebezpieczne, w miasteczkach jest to 14%, a na wsiach 16%.
      Wygląda więc na to, że w naszym regionie ruchy antyszczepionkowe znajdują największy posłuch wśród wykształconych mieszkańców dużych miast.

      « powrót do artykułu
    • By KopalniaWiedzy.pl
      Amerykańska NSA (Narodowa Agencja Bezpieczeństwa) dołączyła do Microsoftu zachęcając użytkowników systemu Windows, by pilnie zaktualizowali swój system operacyjny. W Remote Desktop Services for Windows odkryto bowiem dziurę, która podobna jest do luki, którą w 2017 roku wykorzystało ransomware WannaCry, powodując wielomiliardowe straty na całym świecie.
      Dziura, nazwana „BlueKeep”, może też istnieć w starszych systemach operacyjnych z rodziny Windows, jak Windows 7, Windows XP, Windows Server 2003 oraz Server 2008. Stanowi ona poważne zagrożenie, gdyż szkodliwy kod może rozprzestrzeniać się i zarażać bez interakcji ze strony użytkownika.
      Microsoft poinformował o istnieniu dziury wraz z publikacją w ubiegłym miesiącu odpowiedniej poprawki. Wówczas firma nie zdradziła zbyt wielu informacji. Poinformowano jedynie, że na atak może być narażonych około 7 milionów urządzeń na całym świecie. Później dokładniej przyjrzano się zagrożeniu i liczbę narażonych urządzeń zmniejszono do 1 miliona.
      „BlueKeep”, oficjalnie skatalogowana jako CVE-2017-0708, to krytyczna luka pozwalająca napastnikowi na uruchomienie dowolnego kodu, który kradnie dane i szpieguje użytkowników. Na blogu NSA czytamy: to typ luki, jaką cyberprzestępcy często wykorzystują. Można jej użyć na przykład do przeprowadzenia ataku DoS. Ukazanie się i rozpowszechnienie szkodliwego kodu atakującą tę lukę jest prawdopodobnie kwestią czasu.
      Niektóre firmy zajmujące się cyberbezpieczeństwem już stworzyły prototypowy szkodliwy kod, by móc na tej podstawie stworzyć mechanizmy zabezpieczające. Microsoft i NSA wzywają do pilnego zainstalowania opublikowanej łaty.

      « powrót do artykułu
    • By KopalniaWiedzy.pl
      Niedawno donosiliśmy o wynikach badań, z których wynika, że oceany ogrzały się bardziej niż dotychczas sądziliśmy. Teraz ich autorzy informują, że popełnili błąd w obliczeniach. Podkreślają przy tym, że pomyłka nie falsyfikuje użytej metodologii czy nowego spojrzenia na biochemię oceanów, na których metodologię tę oparto. Oznacza jednak, że konieczne jest ponowne przeprowadzenie obliczeń.
      Jak mówi współautor badań, Ralph Keeling, od czasu publikacji wyników badań w Nature, ich autorzy zauważyli dwa problemy. Jeden z nich związany jest z nieprawidłowym podejściem do błędów pomiarowych podczas mierzenia poziomu tlenu. Sądzimy, że łączy efekt tych błędów będzie miał niewielki wpływ na ostateczny wynik dotyczący ilości ciepła pochłoniętego przez oceany, ale wynik ten będzie obarczony większym marginesem błędu. Właśnie prowadzimy ponowne obliczenia i przygotowujemy się do opublikowania autorskiej poprawki na łamach Nature, stwierdza Keeling.
      Redakcja Nature również postanowiła pochylić się nad problemem. Dla nas, wydawców, dokładność publikowanych danych naukowych ma zasadnicze znaczenie. Jesteśmy odpowiedzialni za skorygowanie błędów w artykułach, które opublikowaliśmy, oświadczyli przedstawiciele pisma.

      « powrót do artykułu
    • By KopalniaWiedzy.pl
      Jak dowiedział się serwis TechCrunch, Gmail przygotowuje opcję samoniszczących się e-maili. Już teraz właściciele niektórych kont mogą skorzystać z ikonki niewielkiej kłódki pojawiające się przy tworzeniu nowej wiadomości. Po jej kliknięciu ustawimy w mailu tryb poufny, który uniemożliwi skopiowanie, przesłanie dalej i wydrukowanie wiadomości. Najprawdopodobniej można też ustawić wygaśnięcie informacji po zadanym czasie oraz wprowadzić wymóg uwierzytelnienia się odbiorcy za pomocą dwustopniowego systemu, w tym wiadomości SMS.
      Nie jest jasne, czy maile są automatycznie są szyfrowane po wybraniu trybu poufnego. Ponadto poufność jest tutaj dość umowna, gdyż nadal istnieje możliwość wykonania zrzutu ekranowego wiadomości, możliwe jest zatem jej późniejsze wydrukowanie czy przesłanie. Nie wiadomo też, czy opcja wygasających maili będzie działała tylko w obrębie kont Gmaila, czy też wiadomość wygaśnie nawet wówczas, gdy jej odbiorca ma pocztę w innym serwisie.

      « powrót do artykułu
×
×
  • Create New...