[js lub inne] Jak wyciagnac z przegladarki historie...

0

Jak w temacie. Potrzebuje skrypt ktory wyciagnie ostatnio odwiedzane strony w przegladarce.
Ostatnio wszedlem w taki link ktory mial uswiadamiac o tym ze nikt nie jest anonimowy i wyswietlil mi ostatnio odwiedzane strony , niestety nie pamietam tego linka i nie moge go znaleŹĆ.
Bardzo bym byl wdzieczny za kod. Nie musi byc on w js. Wazne zeby dzialal

0

Hacker wanted? Okej, za 50PLN powiem ci co to był za hack.

0

W nowoczesnych przeglądarkach nie da się sprawdzić historii przeglądanych stron. Za pomocą hacku można jedynie odpowiedzieć na pytanie, czy użytkownik był na stronie X. Prawdopodobnie w tym linku było właśnie coś takiego: skrypt miał długą listę popularnych serwisów i sprawdzał, na których z nich byłeś.

Trwają prace nad zablokowaniem tego exploita, nie jest to łatwe, ale Mozilla ma pewne pomysły na rozwiązanie i zamierzają je wprowadzić w życie (chyba jeszcze tego nie zrobili). I tak, jest to skrypt JavaScript wykorzystujący... CSS.

0
bswierczynski napisał(a)

Trwają prace nad zablokowaniem tego exploita, nie jest to łatwe, ale Mozilla ma pewne pomysły na rozwiązanie i zamierzają je wprowadzić w życie (chyba jeszcze tego nie zrobili). I tak, jest to skrypt JavaScript wykorzystujący... CSS.

W sumie wystarczy żeby przeglądarka traktowała link zawsze jako nieodwiedzany, kiedy JS prosi o dostęp do stylu.

0

@DM:
Obawiam się, że to nie takie proste. JS może wstrzyknąć do dokumentu nie tylko linki, ale inne elementy -- np. spany zaraz koło linków. A style dla linków odwiedzonych miałyby padding lub jakieś inne własności, które spychałyby spany na bok. I odczytywana byłaby pozycja spanów, a nie aktualne style linków.

Dlatego Mozilla myśli np. o ograniczeniu stylów, jakie przeglądarka akceptowałaby dla odwiedzonych linków. Mógłbyś ustawić powiedzmy kolor tekstu czy tła, ale nie dopełnienia, marginesy i inne własności mogące wpłynąć na pozostałe elementy. I wtedy dopiero można dodać to, o czym wspomniałeś.

0
bswierczynski napisał(a)

@DM:
Obawiam się, że to nie takie proste. JS może wstrzyknąć do dokumentu nie tylko linki, ale inne elementy -- np. spany zaraz koło linków. A style dla linków odwiedzonych miałyby padding lub jakieś inne własności, które spychałyby spany na bok. I odczytywana byłaby pozycja spanów, a nie aktualne style linków.

Dlatego Mozilla myśli np. o ograniczeniu stylów, jakie przeglądarka akceptowałaby dla odwiedzonych linków. Mógłbyś ustawić powiedzmy kolor tekstu czy tła, ale nie dopełnienia, marginesy i inne własności mogące wpłynąć na pozostałe elementy. I wtedy dopiero można dodać to, o czym wspomniałeś.

No przy stylu typu:

a {
   font-weight: bold;
   color: red;
}

a:visited {
   color: orange;
}

Nie ma problemów, tylko po co ktoś miałby bawić się paddingiem/marginesem samego elementu typu "visited" i to jeszcze z poziomu JS? Trochę wbrew usability.

0

@Demonical:
orange to chyba nie kolor css, Opera robi pomaranczowy, ale wiem ze Mozilla kiedys nie chciala. nawet forum Ci nie robi na czerwony/brązowy w kodzie powyzej slowa "orange", ale już "red" tak.

0

@DM:
No po to miałby się bawić, żeby użyć tego exploita na historię.

Ten exploit działa przecież tak, że na SWOJEJ stronie, którą masz pod kontrolą, wstawiasz linki do popularnych witryn, dajesz im style :visited i sprawdzasz, które linki otrzymały styl :visited. Nie musisz dbać o żadne usability. Tak naprawdę te linki i tak robisz ukryte i nikt ich nie zobaczy. To sam kod JS sprawdzi, który link przesunął np. będącego obok spana, bo w :visited dałeś mu padding. Tych stylów dla :visited nie musisz nawet ustawiać z poziomu JS. Mogą one być zdefiniowane w zwykłym arkuszu stylów (a nie: dynamicznie tworzonym przez JS). Z poziomu JS sprawdzasz jedynie konsekwencje.

CSS nie przewiduje ograniczeń co do stylów :visited. Możesz nawet zrobić, aby linki :visited w ogóle się nie wyświetlały. A fajnym efektem np. w niektórych menu (typu lista postów na blogu) dodanie do linków :visited obrazka "ptaszka" -- że wpisy, które przeglądałeś, masz już "odhaczone".

W Mozilli doszli do wniosku, że faktycznie można ograniczyć style :visited do kilku prostych, nie wpływających na layout. Podejrzewam, że nawet bolda nie będzie można użyć, bo on mógłby zwiększyć szerokość tekstu, co jak najbardziej mogłoby wpłynąć na layout i zostać wykryte. Tymczasem kolor tła czy tekstu nie wpływa na inne elementy. A gdy ktoś sprawdzi kolor linku, to przeglądarka może tu kłamać i nie uwzględniać :visited. Gdybyśmy dopuścili paddingi czy nawet te boldy, przeglądarka nie mogłaby w prosty sposób skłamać. Bo z poziomu JS exploiter nie pytałby się o właściwości linka, tylko np. spanu obok niego, czy też elementu nadrzędnego.

0

Tak na prawdę ten :visited nie jest do niczego potrzebny w dzisiejszych czasach. 4Programmers nie oznacza odwiedzanych linków tą klasą, tylko obrazkiem który leci z serwera. Na innych bardziej klasycznych stronach linki są po prostu na fioletowo. Zawsze można przecież wygenerować historię na serwerze.

0

dla prostych stronek to sie nie oplaca (zbieranie jakiejs historii odwiedzonych podstron). osobiscie bardzo lubie :visited, mimo że uzylem go moze w 2 projektach

0

:visited na pewno ułatwia implementację odwiedzonych linków. Jak ktoś ma lepsze rozwiązanie -- po stronie serwera -- to zawsze może go użyć. Natomiast można też polegać na ekstremalnie prostym w implementacji rozwiązaniu z :visited, gdzie cały ciężar implementacyjny przyjmuje na siebie przeglądarka. Warto zauważyć, że :visited jest bardzo stare i wtedy implementacja podobnego zachowania po stronie serwera była relatywnie trudniejsza niż teraz.

Zresztą nawet teraz bardzo trudno byłoby zasymulować cross-domainowe, :visited. Jeśli ktoś odwiedził już jakąś zewnętrzną stronę, ale nie poprzez link na naszym serwerze, to nie mamy jak o tym wiedzieć.

Można się jednak kłócić, czy cross-domainowe :visited jest w ogóle potrzebne. I czy w dzisiejszych czasach nie można żądać, żeby nawet proste strony chcące dać inne style odwiedzonym łączom musiałyby samodzielnie zaimplementować coś w rodzaju :visited.

Jak dla mnie ograniczenie dopuszczalnych stylów dla reguł z selektorem :visited jest całkiem dobrym rozwiązaniem. Tj. nie widzę lepszego. Zapobiegniemy exploitowi, a jak ktoś chciałby jednak mieć bardziej zaawansowane style, to może samodzielnie doklejać klasę np. "visited" po stronie serwera.

Właśnie się skapnąłem, że z listy dozwolonych stylów trzeba by wywalić nawet background-image. Bo odwołania do zasobu na serwerze (obrazka) można by bez problemu rejestrować i na tej podstawie poskładać historię. Także ikony z ptaszkami czy w ogóle jakieś inne nie działałyby w CSS-owym rozwiązaniu.

0

ograniczanie stylów jak dla mnie to zły pomysł. nie lubię jak się mi coś zabiera.

0

Wolisz żeby zabierano Ci prywatność? Jeśli ograniczenie stylów to jedyne rozwiązanie na tego exploita, to nie można tego nazwać "złym pomysłem". To jedyne rozwiązanie poważnego problemu. A że ma minusy, to inna sprawa.

Poza tym możesz samodzielnie zaimplementować historię przeglądania po stronie serwera, tak jak to się dzieje na wielu forach -- w tym 4programmers.net. I wtedy dajesz odwiedzonym linkom klasę "visited" -- lub "umgapalunga", jeśli chcesz się z tym kryć -- i w CSS piszesz nie a:visited tylko a.visited lub a.umgapalunga i masz dostępne wszystkie własności z CSS, bez żadnych ograniczeń.

No chyba że masz jakieś inne rozwiązanie tego problemu? Chętnie posłucham, dla mnie cały exploit jest prosty i ciekawy w swojej elegancji. Niczego mądrzejszego niż Mozilla jednak nie potrafiłem wymyślić.

0

Co przed chwilą wymyśliłem:

user image

Althru, trzeba by do implementacji czegoś takiego użyć albo dwóch oddzielnych kopii DOM, albo modyfikować styl wszystkich elementów :visited w momencie dostępu JS do jakiegoś obiektu na chwilę (nie przedstawiając tego mignięcia użytkownikowi). Ewentualnie zakeszować sobie wartości które prawdopodobnie będą sprawdzane.

0

@DM:
Ja te opcje z miejsca odrzuciłem jako nierealne. Może się mylę, ale...

Modyfikacja DOM "na chwilę"? Śmierdzi to potężnymi problemami wydajnościowymi. DOM to jedno z wąskich gardeł jeśli chodzi o szybkość działania JavaScriptu. Już takie coś w bardzo praktycznych zastosowaniach może być wolne:

var elementCollection = document.getElementsByTagName('div');
for (var i = 0; i < elementCollection.length; i++ {
  processElement(elementCollection[i]);
}

elementCollection to nie tablica, tylko pseudotablicowy zbiór elementów. W specyfikacji DOM jest on zdefiniowany tak, że jeśli w czasie wykonania pętli do dokumentu doszłyby jeszcze jakieś divy, to kolekcja musiałaby zostać odświeżona (!). Przeglądarki realizują to przeważnie tak, że każde odwołanie do elementCollection to tak naprawdę wykonanie zapytania do DOM. Tutaj, w każdym przebiegu pętli mamy dwa odwołania: do elementCollection.length oraz do elementCollection[i].

I to już może być odczuwalnie wolne, więc w krytycznych miejscach skryptów trzeba robić taki cyrk:

var elementCollection = document.getElementsByTagName('div');
var elementArray = Array.prototype.slice.apply(elementCollection, []);
for (var i = 0, n = elementArray.length; i < n; i++ {
  processElement(elementArray[i]);
}

Czyli rezygnujemy z samoczynnego uaktualniania zbioru elementów, konwertując zbiór do zwykłej tablicy. I potem pracujemy na tej zwykłej tablicy, unikając bardzo wielu zapytań do DOM.

Ten cyrk robi się czasem nawet teraz, gdy nie ma żadnego przełączania widoków DOM. A gdy każde odwołanie do własności elementu DOM powodowałoby niejawne przełączenie widoku...?

Intuicja mi podpowiada, że zwolniło by to pracę skryptów wielokrotnie.

Intuicja naturalnie może mylić, szczególnie gdy chodzi o przeprowadzanie benchmarków w głowie :P.

Utrzymywanie dwóch drzew DOM w pamięci też nie bardzo mi się podoba. Już nie chodzi o to, że zwalniałoby to wiele operacji (bo trzeba by je wykonać 2x -- tu może dałoby się wprowadzić jakieś usprawnienia). Duplikacja takich rzeczy w pamięci wydaje mi się po prostu niebezpieczna. JavaScript widziałby inny model dokumentu niż jest w rzeczywistości. No i zastanawiam się co by było z zawartością generowaną. Bo zauważ, że musimy tu myśleć również o CSS3, a nie prościutkich przypadkach z CSS2. Nawet nie wiem jak to jest teraz, a nie chce mi się sprawdzać. Czy np. może istnieć coś takiego jak element:after i czy pseudoelementy powinny być widoczne z poziomu JavaScriptu? A co przy dwóch drzewach DOM: w jednym by były, w drugim nie?

Zresztą, nie trzeba iść tak daleko. Niektóre skrypty polegają na pozycjonowaniu elementów. Odczytują i modyfikują je. I co? Teraz te skrypty miałyby widzieć sytuację inną niż użytkownik? Bo widziałyby bez :visited, a użytkownik widziałby z :visited? Problem w tym, że gdy nie ograniczymy własności dopuszczanych z :visited, to przekłamanie będzie rosło lawinowo. Będzie dotyczyło nie samych linków, ale -- teoretycznie -- niemal dowolnego elementu na stronie. Bo gdzieś tam przeglądarka ściemniała, pomijając np. dodatkowy margines dla elementu z :visited i to poprzesuwało dalsze leementy.

Obawiam się ogromu komplikacji, jakie to może spowodować. A skoro mówimy o rozwiązaniu uniwersalnym, to musiałoby ono uwzględniać wszystkie przypadki (z definicji).

Podejście Mozilli jest przynajmniej uczciwe. Do reguł z :visited można wstawić tylko deklaracje z takimi i takimi własnościami. Resztę ignorujemy. Efektu ignorowanych deklaracji nie zobaczy ani użytkownik, ani skrypt. Dodatkowo, będziemy oszukiwać, gdy spróbujesz odczytać dozwolone własności z poziomu JavaScriptu: wartości zgłosimy tak, jakby linki nie miały :visited. Gwarantujemy jednak, że NIE wpłynie to na inne elementy niż te z :visited i NIE sprawi to, że ułożenie elementów na stronie będzie w rzeczywistości inne niż to zgłaszane przez DOM.

0

@bswierczynski, to nie jedyna, nie pierwsza, i nie ostatnia rzecz, którą o mnie można zebrać z mojego komputera. staram się być jak najbezpieczniejszy, ale nie lubię popadania w paranoje, jak właśnie z tym visited.
ale nie wystarczy jak kto ktoś chyba wspomniał - żeby visited działało tylko w obrębie tej samej strony/domeny?
ew, każda domena osobno miałaby swoje klikniete odnosniki (nie tylko w obrebie swojej domeny),
czyli na stronie moja1.com klikam na odnosnik do onet.pl i on sie staje jakis tam inny
ale na stronie moja2.com nie widac ze onet.pl byl otwierany, bo w jego kolekcji odwiedzonych odnosnikow nic nie ma

0
dzek69 napisał(a)

to nie jedyna, nie pierwsza, i nie ostatnia rzecz, którą o mnie można zebrać z mojego komputera. staram się być jak najbezpieczniejszy, ale nie lubię popadania w paranoje, jak właśnie z tym visited.

Nie uważam tego za paranoję. Sęk w tym, że przed innymi atakami możesz się jakoś tam obronić -- korzystając z bezpieczniejszej przeglądarki, firewalla etc. Tutaj mamy do czynienia ze swego rodzaju exploitem na... specyfikację CSS, czy też na javascriptowe API DOM/BOM. I nic na to nie poradzisz, chyba że w ogóle wyłączysz sobie historię i będziesz wszystko oglądał w porno-mode.

Pewnie, ktoś rozsądny będzie czyścił historię po każdym wejściu na jakieś podejrzane witryny. Ale tu nie chodzi tylko o pr0ny. Nie jest zbyt fajne, że marketingowcy mogą Cię szpiegować i patrzeć, czy wchodzisz na Wykop, Demotywatory, NK czy Onet. Oni po prostu nie powinni mieć dostępu do tych danych bez Twojej wiedzy i zgody -- to naruszenie prywatności.

dzek69 napisał(a)

żeby visited działało tylko w obrębie tej samej strony/domeny?

Tak, gdyby to działo tylko w obrębie domeny, to nie powinno być problemów z prywatnością. Ale tracilibyśmy część funkcjonalności :visited. Bo na razie jest tak, że np. włażąc na Digga widzisz, które linki odwiedziłeś powiedzmy z reddita.

Wydaje mi się jednak, że jest to drugorzędna funkcjonalność. Zresztą tę samą funkcjonalność się straci, jeśli zaimplementujemy nasze własne "visited" po stronie serwera.

Sam pomysł wydaje się jak najbardziej realny i wykonalny. Już teraz działania cross-domainowe są ograniczane, choćby przy żądaniach ajaxowych. Nie sądzę, by sprawdzanie domen w linkach było jakimkolwiek problemem.

Za rozwiązaniem z Mozilli przemawia to, że podstawowe działanie :visited nie uległoby zmianie. Działałoby cross-domainowo, tyle że nie można by było zastosować jakichś wymyślnych stylów (ale tak po prawdzie, to rzadko kiedy się je stosuje dla :visited). Z drugiej strony, jeśli ktoś chciałby ładne linki, to mógłby zaimplementować swoje "visited" na swoim serwerze.

A może najlepsze z obu światów? Linki :visited z tej samej domeny mogłyby być stylowane na wszystkie sposoby, a linki :visited z innych domen miałyby ograniczenia mozillowe.

Tylko takie rozwiązanie mogłoby być niejasne i sprawiałoby pewnie kłopoty mniej obeznanym w temacie webdeveloperom (czemu w połowie linków z :visited działa mi obrazek w tle, a w drugiej połowie nie?).

0

włażąc na Digga widzisz, które linki odwiedziłeś powiedzmy z reddita.

tu jest jakiś argument, ale czy Digg i reddit (nie korzystam) nie wyświetla i tak każdej strony w swojej ramce jak wykop? a więc i tak tego nie widać?

0

Wchodząc na DIGGa i klikając w jakiś link wchodzisz na link pokroju: http://digg.com/story/r/desperate_pic
Z tego linku dostajesz redirect na właściwą stronę, więc w przeglądarce odhacza się, ze wszedłeś na desperate_pic.

W każdym razie ostatnio nawet YouTube zaczął tego hacka używać (jak pamiętam).

0

Z tym Diggiem i Redditem to bardziej chodziło mi o zamysł, o przykład -- nie pokwapiłem się żeby sprawdzić jak oni te linki umieszczają i czy w ogóle mają style :visited (np. na naszym Wykopie również normalne, bezpośrednie linki do znalezisk -- tu :visited by działało, ale... kolesie z wykopu akurat do tych linków nie dali stylów :visited). Jeśli chodzi o ramki to zwykle można je włączyć lub wyłączyć w ustawieniach.

Z tymi linkami /r/(edirect) to słuszna uwaga. Jak tak teraz patrzę na różne serwisy to wydaje mi się, że utrata możliwości cross-domain :visited nie byłaby raczej takim wielkim przypałem. Wiele zaawansowanych witryn specjalnie z tego rezygnuje robiąc właśnie takie linki z redirectami.

Nie dotyczy to jednak np. blogów. Jak tak przeglądam blogi, które śledzę, to tam zewnętrzne linki są zwykłe. I :visited dosyć ładnie działa.

Osobiście mógłbym jednak z tego zrezygnować. Trudno mi oceniać jak by to wpływało na usability w skali globalnej.

Co do Mozilli to oni jeszcze chcieli wprowadzić ustawienie w przeglądarce. Można by w opcjach pozwolić na dowolne stylowanie linków :visited lub włączyć ograniczenie chroniące przed exploitem. Oczywiście, to jest coś fajnego dla bardziej technicznych użytkowników, natomiast nie ma co liczyć, że nie-techniczni by to sobie faktycznie dostosowywali do swoich upodobań.

Jak na to teraz patrzę, to uwzględnianie :visited jedynie dla tej samej domeny wydaje mi się całkiem rozsądne. Na pewno jest wykonalne technicznie, ale powoduje również, że :visited nabiera jednak nowego znaczenia. Wcześniej było powiedziane jasno: jest uniwersalne. Z drugiej strony naprawdę wiele designów i tak nie uwzględnia żadnych stylów :visited (a szkoda). Zaawansowane rozwiązania z oszukiwaniem kodu JavaScript, ale dopuszczające dowolne style (duplikowanie DOM, szybkie przełączanie widoku DOM) budzi moje obawy. Wydaje mi się potencjalnie zbyt kosztowne obliczeniowo, a oszukiwanie JS-u na taką skalę (nie tylko odnośnie koloru elementu, ale również layoutu sporych fragmentów strony) wydaje mi się niebezpieczne. Jeśli chodzi o wydajność to może jakieś zaawansowane keszowanie zdałoby tu egzamin. Tyle że z tym mogłaby być kupa roboty. O ile wiem, obecnie nie ma żadnego duplikowania DOM i oszukiwania JS-u. Łatwo oszukać z kolorem tekstu czy tła, czy też z podkreśleniem, ale gdy dopuścimy do głosu wszystkie własności -- również te wpływające na layout -- zaczyna się robić mały kosmos i intuicyjnie wydaje mi się to niepraktyczne. Choć może popełniam błąd szacowania czegoś na pałę bez dokładnych testów czy nawet porządnej analizy.

1 użytkowników online, w tym zalogowanych: 0, gości: 1