simka
Кодов? Возможно. Изображения? Нет. Еще раз повторюсь, если админка адекватная, ничего кроме реферера в данном случае не передастся.
Да важно ведь не только что передаётся от клиента, но и то, что ему приходит. Вот отдаёте Вы клиенту наружу GIF или PNG, а завтра в очередном UA или библиотеке - опять-таки на стороне пользователя - обнаруживается какая-нибудь уязвимость...
Моё мнение совпадает с мнением pegs. Поддомены заинтересуют правообладателя только если Вы ему ну уж очень насолите.
Kost Troll
Расскажите, кто продавал домен не в RU энду, как это было.
Пакетная сделка, 2x .RU, 2x .COM и 2x .INFO. Был согласован и подписан договор, после чего на банковский счёт была получена первая часть платежа. В соответствии с условиями договора я позвонил правоприобретателю и сообщил, что прямо сейчас в его аккаунт на Moniker будут переведены .COM и .INFO домены, после чего, зная Transaction Authorization Code правоприобретателя, я выполнил в своём аккаунте процедуру Push. На этом передача этих 4-х доменов была завершена.
Kost Troll, а почему бы не проделать ту же операцию в своём офисе, офисе покупателя или с использованием, скажем, своего ноутбука? Подключаетесь тем или иным образом к Internet, заводите аккаунт покупателю (или в случае лёгкой формы паранойи он заводит его себе сам, возможно следуя Вашим инструкциям), получаете деньги, делаете Push. Всё.
По очень похожей схеме передавались gTLD-домены, зарегистрированные в Moniker.
Тема свелась к банальному хамству и флуду.
79567144, Ваше доменное имя (точнее, зона этого домена) не размещена на серверах Вашего хостинга. Пишите в поддержку хостера.
MEDIA IMAGES, перспектива подобного иска устрашающе стремится к нулю, т.к. предъявлять нечего. Теоретически можно как-то подкопаться под рассылку, произведённую RU-Center (да и не только им, к слову!) по своим клиентам, но перспектива тоже выглядит призрачно.
Если уж на то пошло, то лучше прикладывать усилия к продвижению своего мнения в широкие массы пользователей.
P.S. Личку видел, отвечу позже.
pelvis, если речь пойдёт о спорах типа "Вы заняли "наш" домен, по какому праву?!", то ситуация здесь может быть разной. ICANN я бы посоветовал установить единые правила рассмотрения подобных споров для подобных частных TLD (думаю, что стоит называть их именно частными - сокращённо pTLD - private TLD). Мотивация проста: в подобного рода делах должен быть очень жёсткий порядок и контроль, до уровня "железной руки", а отдав политику разрешения споров на откуп каждому конкретному администратору pTLD, мы получим бардак, отсутствие рычагов давления и прочая, прочая. Своё слово должны сказать и WIPO и UN.
Ну и в любом случае никуда не денутся обычные суды. Вам никто не сможет запретить обращаться за защитой своих прав именно туда.
Ведь всему миру до .msk дела нет. Они считают это просто .LLL
google://msk - вполне возможно, что на ту же .MSK будет претендовать кто-либо ещё. Так что аукцион, конкурс, тендер - и откаты и взятки. И не говорите мне, что "за бугром" их нет.
Andris добавил 27.06.2008 в 15:38
А вообще очень жаль и одновременно очень интересно наблюдать за началом конца Internet. Сначала IDN, затем pTLD, потом Private Root, далее... А что далее? IMHO за периодом сепаратизма (а всё вышеперечисленное, в особенности IDN, есть ни что иное, как сепаратизм чистой воды) по логике вещей следует период успокоения эмоций, а затем - объединения в том или ином виде и с тем или иным количеством "крови".
pelvis, куча претендентов встретятся - заочно ли, вживую ли - на аукционе. Об этом уже упоминал Twomey.
snuker, перевод с технического :):
На DNS-сервере хостера в файле, определяющем, какие имена будут работать в Вашем домене, отсутствует специальная запись *, работающая точно также, как и маска файлов * - т.е. "все имена в текущей иерархии". Смену DNS-серверов для домена можно произвести так, что историй, подобных описанной Вами, можно практически полностью избежать, но для этого нужно иметь полный контроль над записями в домене - в частности, необходимо иметь возможность изменять параметр TTL (Time-To-Live, время жизни) конкретных записей или хотя бы контролировать глобальное значение этого же параметра, применяемое для всех записей. Работу по смене DNS-серверов (читай: хостинга) нужно планировать и начинать заблаговременно.
