Новые книги

Биткойн – это пиринговая платежная система и финансовая технология, ломающая многие привычные представления о деньгах и их роли в обществе. В этой книге представлена невероятная история о том, как идея подобной системы, изначально интересная лишь маленькой группке энтузиастов, постепенно привлекла к себе внимание всего мира.

В этой истории принимают участие самые неожиданные персонажи: финский студент и аргентинский миллионер, китайский предприниматель и программист-создатель Netscape, неудавшийся физик, ставший онлайн-наркобароном, и близнецы-плейбои, засудившие главу Facebook, акулы венчурного капитала и руководители крупнейших мировых банков, прокуроры, спецагенты и сенаторы США, ну и конечно, сам отец-основатель Биткойна, известный под псевдонимом Сатоши Накамото. И хотя многих ставит в тупик сама мысль о цифровой валюте, за которой не стоит мощное государство или центробанк, энтузиасты Биткойна во всем мире, от Пекина до Буэнос-Айреса, верят в потенциальную возможность этой финансовой системы стать всемирно признанными деньгами цифровой эпохи.

Книга адресована тем, кто интересуется современными финансовыми системами, и в частности, криптовалютными технологиями.
Художникам приходится делать множество вещей, с творчеством никак не связанных. Да-да, чтобы найти свое место в мире искусства, только лишь таланта и усердия недостаточно. Созданные работы нужно где-то выставлять, покупателей на них – искать, и все это порой сопровождается немалым количеством бумажной работы. Авторы этой книги побеседовали с десятками людей: художниками и галеристами, кураторами и юристами, организаторами художественных ярмарок и даже сотрудниками транспортных компаний. Составленное ими руководство – незаменимая книга для любого художника. Вы найдете в ней множество полезных советов буквально обо всем, что вам следует знать: поиски галереи и подача заявки на грант, выбор резидентской программы и оформление документов, упаковка работ и расположение их в пространстве. Упорядочив свою профессиональную жизнь во всех этих аспектах, вы будете больше времени уделять тому, чем и должны заниматься: искусству.

Воспрепятствование автоматизированному миррорингу Веб-узла

Воспрепятствование автоматизированному зеркалированию Веб-узла

Некоторое время назад в рассылке Apache-Talk была дисскуссия, переросшая в сильнофилософские рассуждения о невозможности полной защиты узла от скачивания с доказательствами и т.п., что говорит о хорошем уровне академического образования уважаемых коллег по майл-листу...

Интересное наблюдение как-то мне поведал один из работающих у нас мужичков: "Если дать.... ну нерешаемую задачу студенту (выпускнику) МГУ (в его случае МехМат) и ФизТеха, то (с большой вероятностью) МГУ'шник начнет доказывать невозможность решить задачу, а ФизТех'овец начнет пытаться ее решить. Пусть не на всех возможных значениях параметров, но все же... ау, МехМат! И хоть сам я являюсь представителем школы МГУ (правда, не МехМат а ВМиК), попробую (хоть тут) чуток поопровергнуть такое мнение относительно родной Альма-матер.

Врочем, извините за столь длинное вступление. Итак, хочу немножко поделиться мыслями (возникшими в связи со вчерашней бессонницей) на тему "воспрепятствование автоматизированному миррорингу Веб-узла".

1. JavaScript. До чего ж люблю я Netscape... такую классную штуку придумали. А подлый Microsoft его передрал - а когда пишешь, что MS JavaScript не совместим с оригинальным - отписывают: "У нас, мол, не JavaScript, а JScript." Почувствуйте разницу.

Итак, как мы обычно описываем ссылки?

<a href='file.html'>Ссылка</a>.

А кто сказал, что это единственный способ их описания? Вот почти тоже самое:

<a href='javascript:document.location =
 "file.html"'>Ссылка</a>

Каюсь, таким образом отсекаются пользователи Lynx'а и некоторых браузеров, не поддерживающих JavaScript. Но если человеку сильно нужно посмотреть сайт, то он запустит-таки Netscape. А в связи с тем, что сайт хотят смироррить, вероятность этого "нужно" довольно высока.

Конечно, можно научить wget брать подобные ссылки. Но можно ведь пойти дальше:

<script> Link = 'file.html' </script>
...
<a href='javascript:document.location = Link'
>Ссылка</a>

Кроме того - а кто сказал, что ссылки необходимо размещать явно в теле документа:

<script> document.write(unescape('%3C') + 'a hr' +
'ef="file.html">' + 'Ссылка' + unescape('%3C') + '/a>')
 </script>

Понятное дело, этим дело далеко не ограничивается, и тут уже приходится писать wget, который занимается интерпретацией JavaScript. Причем не как статический JavaScript, а динамический (где-то в конце документа):

<script> setTimeout
('Link = "file1.html"', 1000) </script>

Пойди догадайся, что и в какой момент будет в переменной Link. Решениеи идти по всем возможным значениям переменных натыкается на такой веселый код:

<script>

function a()
{
  if (confirm('Are you stupid?')) while(1)
   do_nothing();
  location = 'file.html';
}
...
<a href='javascript:a()'>Ссылка</script>

Как думаете, чем будет заниматься такой интеллектуальный wget?

Таким образом, грамотное использование JavaScript практически решает задачу. Задача написания столь высокоинтеллектуального wget'а, на мой взгляд, настолько дорогостоящая, что никто этим заниматься не будет.

2. "Добрые ссылки". Напишем простенький CGI (поклонники Perl'а не бить! Ну не силен я в Perl'е):

// surprise.c ==> surprise.cgi
#include <stdio.h>
#include <stdlib.h>

main()
{ 
  int i = 0;

  if (getenv("QUERY_STRING")) i = atoi(getenv(
  "QUERY_STRING"));

  printf("Content-type: text/html");
  printf("\n");
  printf("<a href='surprise.cgi?%d'>%d</a>\n", i, i);
}

При вызове 'surprise.cgi' он выдает ссылку на 'surprise.cgi?1', тот в свою очередь на 'surprise.cgi?2' .... "У попа была собака". Как думаете, за сколько умный wget выкачает такую ссылку?

Только не говорите, что wget не будет качать CGI. Никаких нет проблем (с помощью аккуратной настройки Apache "ErrorDocument 404" и nph-CGI) сделать директорию, при обращении к которой последовательно выдаются ссылки на '1.html', '2.html' ...

Проблема так-же не решается ограничением глубины поиска для wget'а. Никто не мешает модифицировать предыдущий вариант так, чтоб при обращинии к файлу с любым именем в данной директории выдается HTML содержищий 10 (100) ссылок на файлы с произвольными именами в той-же директории. При глубине скачивания три (что явно недостаточно ) wget'у придется скачать с сайта 100 + 100*100 + 100*100*100 файлов. Не знаю, сколько времени ему, бедолаге, на это потребуется.

Наводните документы ссылками типа

<a href='surptise.cgi'>Don't click this link!!!</a>

или

<a href='/surprise/xmm.html'><img src='1x1.gif'
 border=0 heigth=1 width=1></a>

и wget будет бессилен... где-то в Инете я видел сайт, который генерирует N (задается пользователем через форму) килобайт почти связанного русского текста. Сгенерите такой текст, разбавив его ссылками в '/surprise/' ...

Подведу некоторые итоги. Никто не говорит о теоретическом решении этой задачи. Теоретически можно скачать все. Практически же... Теоретически можно поставить друг на дружку 10 яиц. Практически... да хоть одно поставьте! Разве что Наполеон (поправьте меня, если это не он) решил эту задачу надломом яйца :-)) Да, можно яйцо поставить на конец раскрутив его (surprise.cgi, href='javascript:location=..'), а 10 уже никак не поставишь.... хотя это и возможно теоретически.

Проблема, как мы видим, решается довольно простыми методами. Никто не говорит об абсолютном запрещении мирроринга. Но очень сильно подпортить кровь желающим это сделать можно элементарно, что делает задачу оного мирроринга практически невыполнимой и малорентабельной.