The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

EFF считает, что замена отслеживающих Cookie на FLoC может привести к новым проблемам , opennews (ok), 06-Мрт-21, (0) [смотреть все] +1

Сообщения [Сортировка по времени | RSS]


185. "EFF считает, что замена отслеживающих Cookie на FLoC может п..."  –3 +/
Сообщение от Аноним (6), 07-Мрт-21, 00:38 
Говно собачее этот Gemini. Я его автору написал, какие недостатки в его протоколе и в предположениях, сделанных им о протоколе. Ответов до сих пор не последовало. Поэтому приведу тут.

1. Автор утверждает, что гемини сделан быть нерасширяемым. Это не так. Всегда можно добавить своих тегов, и сообщение с инструкциями, как поставить свой клиент. Свой клиент это сообщение рендерить по-умолчанию не будет. На сервер данные можно пересылать как часть URI. Можно сказать, что эть уже не гемини. Но это будет гемини: можно притвориться, что это не теги расширения, а плеинтекст.

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

3. Заявляется, что оставлены простые теги. Но они несемантические. А надо было оставлять исключител ьно семантические.

4. Формат - текстовый. Его трудно парсить. Лучше бы был бинарный, напр msgpack - его легче парсить, а оверхеда меньое.

5. Упоминается gopherspace. .. в 2021. Этот гофер даже в нулевых почти никто уже не юзал.

У проекта нет будущего. Вместо переизобретения ненужных велосипедов следует стандартизировать протоколы взаимодействия с типовыми сайтами поверх http и jskn.

Ответить | Правка | К родителю #159 | Наверх | Cообщить модератору

195. "EFF считает, что замена отслеживающих Cookie на FLoC может п..."  +/
Сообщение от Аноним (195), 07-Мрт-21, 06:09 
>Я его автору написал, какие недостатки в его протоколе и в предположениях, сделанных им о протоколе. Ответов до сих пор не последовало.

Если ты писал ему то же самое, то неудивительно, что он не ответил.

>Всегда можно добавить своих тегов, и сообщение с инструкциями, как поставить свой клиент.

Можно, но это будет не гемини.

>Формат - текстовый. Его трудно парсить. Лучше бы был бинарный

Наоборот, с текстом легче работать, для его обработки больше инструментов и он человекочитаем.

>следует стандартизировать протоколы взаимодействия с типовыми сайтами поверх http и jskn.

Начинай

Ответить | Правка | Наверх | Cообщить модератору

196. "EFF считает, что замена отслеживающих Cookie на FLoC может п..."  +/
Сообщение от Аноним (6), 07-Мрт-21, 06:21 
>Можно, но это будет не гемини.

Никого не волнует, gemini или нет он по духу. Если его другте клиенты схавают - значит gemini. Значит либо ставь расширяемый клиент не-гемини, либо терпи на странице всякую ненужную гадость, у тебя не работающую, либо проваливай.

>Наоборот, с текстом легче работать, для его обработки больше инструментов и он человекочитаем.

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

>Начинай

За меня Tapatalk начал.

Ответить | Правка | Наверх | Cообщить модератору

204. "EFF считает, что замена отслеживающих Cookie на FLoC может п..."  +/
Сообщение от Аноним (195), 07-Мрт-21, 07:26 
>Если его другте клиенты схавают - значит gemini.

Если клиент схавает и отрисует html5, то это не превратит оный в gemini.

>В текстовых нужен эскейпинг, и серьёзные извращения при написании грамматики, и огромный геморрой при её отладке.

Экранирование нужно - страсти-то какие. Мда, это весомый довод, чтобы лишить пользователя возможности грепать странички, редактировать их в своем любимом редакторе, просматривать сайты, имея один лишь curl под рукой.

Ответить | Правка | Наверх | Cообщить модератору

222. "EFF считает, что замена отслеживающих Cookie на FLoC может п..."  –1 +/
Сообщение от Аноним (6), 07-Мрт-21, 11:05 
>Мда, это весомый довод, чтобы лишить пользователя возможности грепать странички

А кто лишает? Текст в бинарных блобах остаётся как есть.

>редактировать их в своем любимом редакторе.

С этим засада, без специального софта не обойтись. Такого, как конвертор msgpack <-> yaml. Если задействовать bencode, то конвертор не понадобится, но понадобится калькулятор и текстовый редактор с указанием байтовой позиции курсора.

>просматривать сайты, имея один лишь curl под рукой.

cURL поддерживает http/2 и даже http/3.

Ответить | Правка | Наверх | Cообщить модератору

230. "EFF считает, что замена отслеживающих Cookie на FLoC может п..."  +2 +/
Сообщение от Аноним (230), 07-Мрт-21, 15:02 
>А кто лишает? Текст в бинарных блобах остаётся как есть.
>конвертор msgpack <-> yaml.
>Если задействовать bencode
>понадобится калькулятор и текстовый редактор с указанием байтовой позиции курсора.

/O\
Впрочем, с первого сообщения было ясно, что отвечать смысла не имеет

Ответить | Правка | Наверх | Cообщить модератору

242. "EFF считает, что замена отслеживающих Cookie на FLoC может п..."  +/
Сообщение от Ordu (ok), 08-Мрт-21, 04:39 
>>Формат - текстовый. Его трудно парсить. Лучше бы был бинарный
> Наоборот, с текстом легче работать, для его обработки больше инструментов и он
> человекочитаем.

Приколись, когда я пишу программки на C или Rust'е, эти программки -- о ужос, -- компилируются в бинарный код. То есть, если присмотреться, я работаю с бинарным кодом, я часто думаю о том, что я пишу, в терминах машинных инструкций, которые сгенерятся из тех строчек кода, которые я пишу. И я бы не сказал, что это сильно менее удобно, чем писать на Python'е и исполнять непосредственно написанный мною текст.

Нельзя сказать, что прочитать elf так уж просто -- в linux'е явный недостаток инструментов, которые позволяют это сделать. То есть при наличии отладочной информации можно и довольно удобно, но когда отладочной информации нет -- это кошмар. И ничего, никого это особо не заботит. То есть, последнее время появился, например, radare, но я так и не выбрал времени научиться им пользоваться.

Ответить | Правка | К родителю #195 | Наверх | Cообщить модератору

243. "EFF считает, что замена отслеживающих Cookie на FLoC может п..."  +1 +/
Сообщение от Аноним (230), 08-Мрт-21, 05:39 
Ну и что ты этим пытался сказать или оспорить? Просто похвастаться, мол, на расте и си пишу? Молодец.
>если присмотреться, я работаю с бинарным кодом

Нет. Работаешь ты с кодом, который текст.
>я часто думаю о том, что я пишу, в терминах машинных инструкций

Какое богатое у тебя воображение.

Ответить | Правка | Наверх | Cообщить модератору

244. "EFF считает, что замена отслеживающих Cookie на FLoC может п..."  +/
Сообщение от Ordu (ok), 08-Мрт-21, 06:44 
> Ну и что ты этим пытался сказать или оспорить? Просто похвастаться, мол,
> на расте и си пишу? Молодец.

А ты не пишешь? Ты считаешь, что тут есть чем хвастаться?
>>я часто думаю о том, что я пишу, в терминах машинных инструкций
> Какое богатое у тебя воображение.

А ты не думаешь? В смысле? Ты пишешь на низкоуровневых языках, и не думаешь о том, в какой машинный код скомпилируется? Может ты действительно не пишешь на низкоуровневых языках, может ты на пайтоне пишешь? Не, ну реально, зачем писать на расте, C, C++, паскале, не думая о машинном коде, когда с тем же успехом можно писать на java, python, js, и прочих языках, которые специально созданы так, чтобы не думать о таких мелочах.

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

>>если присмотреться, я работаю с бинарным кодом
> Нет. Работаешь ты с кодом, который текст.

Что помешает работать с кодом "бинарного html'а", как с текстом?

Ответить | Правка | Наверх | Cообщить модератору

245. "EFF считает, что замена отслеживающих Cookie на FLoC может п..."  –2 +/
Сообщение от Аноним (245), 08-Мрт-21, 09:18 
>Ты пишешь на низкоуровневых языках, и не думаешь о том, в какой машинный код скомпилируется?

Нет, конечно. Это бесполезно и даже вредно, потому что мешает писать переносимый и прозрачный код. Особенно некоторым умникам, которые своими кривыми "оптимизациями" плодят уязвимости.

>на расте
>C++
>не думая о машинном коде

Сейчас бы гадать, во что скомпилируются языки без ABI, лол.

>Что помешает работать с кодом "бинарного html'а", как с текстом?

Зачем вообще перегонять текст туда-обратно? Форматы изобретают, чтобы решить проблему, а не создать пачку новых.

Ответить | Правка | Наверх | Cообщить модератору

247. "EFF считает, что замена отслеживающих Cookie на FLoC может п..."  +1 +/
Сообщение от Ordu (ok), 08-Мрт-21, 11:24 
>>Ты пишешь на низкоуровневых языках, и не думаешь о том, в какой машинный код скомпилируется?
> Нет, конечно. Это бесполезно и даже вредно, потому что мешает писать переносимый
> и прозрачный код. Особенно некоторым умникам, которые своими кривыми "оптимизациями" плодят
> уязвимости.

Если ты не думаешь о машинном коде, то ты не пишешь эффективный код. Если ты не думашь о нём, то я не знаю, как ты в C обходишь UB, если честно, то есть подозреваю, что ты как раз плодишь уязвимости, когда не думаешь.

А если ты не веришь мне, то я заверяю тебя, я не один такой. Из тебе известных людей, я могу сослаться, например, на Торвальдса, он точно заявлял такое. Думаю в его Just for Fun.

>>на расте
>>C++
>>не думая о машинном коде
> Сейчас бы гадать, во что скомпилируются языки без ABI, лол.

Не надо гадать. Если ты не знаешь, во что код скомпилируется, то компиляешь в асм и смотришь.

>>Что помешает работать с кодом "бинарного html'а", как с текстом?
> Зачем вообще перегонять текст туда-обратно? Форматы изобретают, чтобы решить проблему,
> а не создать пачку новых.

Эээ... Да ты, я вижу, не разделяешь данные и формат данных. Ты не писал никогда на лиспе? Попробуй. Это очень развивающе тебе будет. Там есть текстовое представление для любого объекта, а если представление в памяти. Для некоторых объектов, скажем для функций, может быть аж целых три разных представления в памяти, в одной лисп-машине -- в виде лисповского списка, в виде байткода, в виде нейтив-кода. Поначалу, когда сталкиваешься с лиспом, это иногда даже сбивает с толку, но потом привыкаешь думать о данных как о данных, а о форме хранения этих данных как о преходящем их свойстве. (upd. а, да, забыл сказать главное, у каждого объекта ещё есть текстовое представление, в котором его всегда можно вывести на экран, и, скажем, скопипастить в сорец)

И это очень полезно о таких вещах думать. В том же C, например, твои int'ы постоянно меняют своё бинарное представление, потому что ты не следишь за всеми случайными преобразованиями, которые возникают. То у тебя char стал int'ом, потом вдруг опять char'ом... Бинарное представление меняется, а значение остаётся тем же. Из этого, кстати, вполне могут вылезать баги, потому что нечаянно можно отрезать несколько бит от инта.

Или когда работаешь с внешними данными, например, когда был зоопарк кодировок, и внутренняя кодировка используемая в программе могла быть фиксированной (скажем utf8 или wchar_t), а внешняя какой угодно. Понятно, что вся эта работа с кодировками и преобразование строк туда-сюда инкапсулировалась максимально, чтобы в логике алгоритмов не путаться под ногами, но во-первых, инкапсуляция часто оказывалась протекающей (потому что перекодировать килобайт, только чтобы потом перекодировать его обратно, было довольно странно), а, во-вторых, сам слой инкапсуляции требовал думать об одной и той же строке, которая иногда меняет своё представление.

Ответить | Правка | Наверх | Cообщить модератору

248. "EFF считает, что замена отслеживающих Cookie на FLoC может п..."  +/
Сообщение от Аноним (245), 08-Мрт-21, 12:18 
>Если ты не думаешь о машинном коде, то ты не пишешь эффективный код.

Думай лучше об алгоритмах и структурах данных, пиши прозрачный, гибкий, масштабируемый и переносимый код. Компилятор заоптимизирует намного лучше, чем ты.

>Если ты не думашь о нём, то я не знаю, как ты в C обходишь UB

А я тебе подскажу: необходимо и достаточно знать стандарт. А во что скомпилируется код - ты никогда не угадаешь, это зависит от применённых оптимизаций, от версии компилятора, платформы, архитектуры.

>Эээ...

Опять ты мыслью по древу растёкся. Повторю вопрос: зачем перегонять в бинарный формат? Какую проблему ты этим решаешь? Какие создаешь - уже выяснили.

Ответить | Правка | Наверх | Cообщить модератору

250. "EFF считает, что замена отслеживающих Cookie на FLoC может п..."  +/
Сообщение от Ordu (ok), 08-Мрт-21, 14:47 
>>Если ты не думаешь о машинном коде, то ты не пишешь эффективный код.
> Думай лучше об алгоритмах и структурах данных, пиши прозрачный, гибкий, масштабируемый
> и переносимый код. Компилятор заоптимизирует намного лучше, чем ты.

"Прозрачный", "гибкий", "масштабируемый", "переносимый" -- ты чё, курсов для эффективных менагеров в IT наслушался? Код надо писать в первую очередь таким, чтобы его можно было бы сопровождать. А всё остальное -- это уже определяется условиями конкретного проекта. На самом деле, если уж так говорить, то и возможность сопровождения не всегда важна. Нахрена мне писать масштабируемый или переносимый код, если я пишу для микроконтроллера? Можно подумать о том, чтобы заложить возможность портирования на другой микроконтроллер из того же семейства, да и то если есть осознанные причины так делать, и если это не требует больших усилий. А масштабироваться -- куда? На кластер из микроконтроллеров? "Гибкий" -- это что вообще такое? Это в каком смысле гибкий? Это в смысле, что я потом легко смогу внести изменения в код, обеспечив его повторное использование в другом проекте, или в смысле virtual на vitrual'е virtual'ом погоняет, и в результате мы получаем чуть ли не C++ с динамической типизацией, и всё ради абстрактной идеи повторного использования и гибкости, которые внезапно могут никогда не потребоваться этому коду? А вот работать ему потребуется, и сквозь весь этот динамизм прорываться тоже. Или в каком-то ещё смысле гибкий?

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

>>Если ты не думашь о нём, то я не знаю, как ты в C обходишь UB
> А я тебе подскажу: необходимо и достаточно знать стандарт. А во что
> скомпилируется код - ты никогда не угадаешь, это зависит от применённых
> оптимизаций, от версии компилятора, платформы, архитектуры.

Стандарт знать надо. А что там на разных архитектурах творится, по-хорошему, не сильно важно. Они все примерно одинаковы. Если на одной норм получается, то и на другой получится неплохо. Больше вариаций привносит не архитектура, а реализация архитектуры, например, есть ли у неё конвееры, какой они длины, сколько их, кеширует ли эта реализация память, сколько там кеша под инструкции... Но с конвеерами компилятор неплохо справляется, а кеширование памяти сегодня отсутствует разве что в микроконтроллерах, то есть если ты не для мк пишешь, то можешь смело рассчитывать на кеширование, но вот оно кстати очень сильно влияет на структуры данных и алгоритмы, которые тебе следует выбирать, а для этого надо думать о кеше, о том как работает процессор, о том, к каким данным ты сейчас пытаешься обратиться -- к тем что в регистрах, в кеше, в оперативке?

>>Эээ...
> Опять ты мыслью по древу растёкся. Повторю вопрос: зачем перегонять в бинарный
> формат? Какую проблему ты этим решаешь?

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

Ответить | Правка | Наверх | Cообщить модератору

265. "EFF считает, что замена отслеживающих Cookie на FLoC может п..."  +/
Сообщение от Аноним (265), 10-Мрт-21, 00:48 
Это ты ответь, зачем перегонять в текстовый из бинарного. Бинарные парсятся в одном направлении обычно, а парсер пишется приятно и легко. Текстовые - это нужно генерировать автомат, с откатами. В бинарных такого нет.

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

Ответить | Правка | К родителю #248 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру