Как регулировать технологические платформы (приложение)
Приложение: серверная совместимость
На первый взгляд прозрачность протоколов звучит похоже на тот же регуляционный подход, который предлагали Кори Доктороу и EFF: серверная совместимость с открытыми, стандартными, федеративными API. На деле же эти подходы довольно сильно различаются, хотя прозрачность протоколов и можно рассматривать, как вариант “делегирования” Доктороу.
Замысел серверной совместимости в том, чтобы заставить социальные сети работать по тем же техническим принципам, что и электронная почта. Это хороший, здоровый и позитивный инженерный замысел.
Если бы электронная почта работала как Twitter, все бы пользовались Gmail, и все сообщения бы загружались прямо в Google. Если бы Twitter работал как электронная почта, вы бы использовали стандартный протокол для загрузки вашего твита вашему провайдеру твитов, который бы использовал другой стандартный протокол, чтобы поделиться им с провайдерами твитов ваших друзей.
Это технически нетрудно. Это не Звездный Путь, хотя такая система и называется “федерацией.” Между прочим, существует маленькая, но процветающая федеративная социальная сеть, называющаяся "Mastodon,” у которой есть своя собственная настоящая культура, чьи ценности примерно соответствуют ценностям Звездного Пути. Давайте же склоним наши федоры перед Mastodon и его “гудками” [“toot” — аналог твитов в Mastodon — пр. пер.].
Но федеративные социальные сети так и не стали мейнстримом — по социальным и экономическим, а не по техническим причинам. Я помню, как еще будучи совсем молодым, я попал на встречу IETF по стандартизации федеративных социальных сетей — в 1997. Эта рабочая группа разработала стандарт XMPP, который так и не стал популярным. Мейнстримные сети иногда пытались федерироваться с XMPP и иными протоколами. Эти федеративные интерфейсы вскоре стали городами-призраками и шлюзами для спама и были отключены.
(Mastodon по большей части не страдает от спама по тем же причинам, по которым от него был свободен Интернет до середины 90-х: определенный сорт пользователей. Те, кто пользуются Mastodon, не спамят и не попадаются на спам. Но это только потому, что Mastodon не мейнстримен. Его решение проблемы спама в основном состоит в том, что ему еще не нужно решать эту проблему.)
Федерация — это хорошо. Открытые стандарты — это хорошо. Mastodon (или его стандартный ActivityPub) — это хорошо. Однако серверная совместимость как регулятивная стратегия заставляет эти компании решать проблемы, которые Интернет пытается решить вот уже 25 лет. А еще они на самом деле не хотят решать эти проблемы, хотя, возможно, многие их инженеры и хотели бы. Многие инженеры этих компаний родились в 1997 году и/или идентифицируют себя как драконы.
Поэтому регуляция, заставляющая платформы предоставлять федеративные сервисы, заставляет их создавать вынужденное API [compliance API в оригинале — пр. пер.]: программную подсистему, существующую только по регуляторным причинам. В природе ПО — не работать, или хотя бы не работать хорошо. В природе вынужденного API — делать вид, что оно работает — в каком-то смысле, в теории.
Если вынужденное API также станет открытым стандартом, его бесполезность станет комичной. В природе стандартов — приниматься вечно. В природе реализаций — быть несовместимыми. Никто не будет вкладывать столько сил во что-то, если они не хотят, чтобы оно работало, и даже не знают, как заставить это что-то работать — как минимум социально и экономически.
У регуляций есть свои ограничения. Регуляторы не могут заставить компанию или индустрию изобрести решение для нерешенной проблемы. Не нужно быть калифорнийским либертарианцем, чтобы предположить, что король Кнуд — не самая лучшая модель для современных регуляторов.
Прозрачность протоколов же, напротив, открывает протоколы, которые компании действительно используют. Все, что компаниям нужно сделать — это предоставить права и открыть документы, и исправить весь серверный код, который подразумевает некоторое доверенное приложение-клиент. Но такой код — итак баг.
Приложение: ответственность за модерацию платформы
Кое-кто также продвигает различные попытки исправить различные законы, например, печально известный “раздел 230,” с целью сделать платформы ответственными за несправедливую модерацию. Все эти попытки — нелепые аферы, которые в лучшем случае безвредны, и такие предложения необходимо отвергать без права на апелляцию.
У этих попыток множество первых шагов. У них у всех один и тот же последний шаг: судьи запрещают платформам цензурировать консерваторов. Это чушь. Платформы не цензурируют консерваторов! Они модерируют разжигание ненависти, осознанную и неосознанную дезинформацию, преследование, порнографию, хулиганизм, богохульство, сыновью непочтительность, отрицание физики, расизм и отрицание рас, оскорбления Пророка и/или контрреволюционную агитацию…
У всех этих платформ есть отделы по модерации, с численностью, превышающей численность танковой дивизии Вермахта, инструкциями, в которых могли бы потеряться налоговые декларации президента, и объемом работы, требующим девять решений в миллисекунду. Для любого человека, хоть что-то слышавшего о задержке, пропускной способности и стабильности американской судебной системы, предложение подвергнуть эту машину осмысленному и эффективному регуляторному контролю, какой бы ни был формальный повод, какой бы ни была политическая или интеллектуальная цель, кажется настолько же осмысленным, как вторжение на Кубу с армией овец-амфибий. Беее.
Впрочем, ответственность платформ может породить один конкретный эффект: аналог отмененной доктрины честности FCC, но для социальных сетей. Если прошлое может служить нам примером, в конечном счете это приведет к тому, что платформы будут нести ответственность за то, что они не цензурируют консерваторов. “Вы смеетесь. Вы смеетесь, но это не смешно.”
Приложение: личные облачные сервера
Впрочем, регуляции, связанные с прозрачностью протоколов — не самое правильное решение.
Это милый хак; может быть, это даже эффективный или правильный хак; но это хак. Хак — это не будущее. (Кроме того, его, скорее всего, будет весьма трудно реализовать по политическим причинам.)
Правильное решение заключается в том, что у каждого должен быть свой собственный сервер. Вместо того, чтобы жонглировать кучей аккаунтов на разных платформах, вы будете владеть одним личным сервером, на котором будут работать различные приложения, и который будет хранить вашу информацию, пока вы не умрете.
Этот сервер все еще где-то размещен. Он находится в дата-центре какой-то компании (“облако”). Это все еще просто виртуальный компьютер. Но он полностью ваш. Никто не может вам указывать, что вы должны с ним делать, или наказать за то, что вы делаете что-то, что кому-то не нравится — если вы только себя не задоксите, конечно.
Но ваши данные все еще находятся на складе какой-то случайной компании. Как они могут быть на самом деле вашими?
Для хостера уже сложно и необычно (хотя и технически возможно) подключиться к виртуальному компьютеру и считывать с него данные или записывать их на него. Таких структурных брандмауэров между вашим профилем в Facebook и кодом Facebook, который должен считывать и записывать данные, не существует. Но ваш профиль Facebook — это не самозапускающийся компьютер общего назначения.
У хоста есть все коммерческие стимулы поддерживать неприкосновенность вашей виртуальной машины — до тех пор, пока он не получит правительственное распоряжение. Тогда у него появляются все стимулы препарировать вас живьем. Но тут новейшие технологии неиронично меняют мир в лучшую сторону.
Новые чипы Intel и AMD позволяют хосту укрепить этот брандмауэр даже против самих себя, с минимальными затратами, с помощью технологии, называющейся защищенные анклавы. Защищенные анклавы позволяют хосту запускать ваш виртуальный компьютер так, что даже сам хост не сможет считывать или записывать на него данные. Хост даже сможет игнорировать правительственные распоряжения — потому что он ничего не сможет сделать.
Google уже продает защищенный хостинг под названием Confidential Computing. Google не предлагает защищенный хостинг за анонимную криптовалюту. Но кто угодно может купить чип AMD. С добавлением еще одной проверенной технологии, луковой маршрутизации (Tor), примерный набросок будущей цифровой конфиденциальной утопии становится четко виден.
Если вы сможете владеть личным сервером на блокчейне, запускать его на защищенном анклаве какого-нибудь хоста и общаться только через луковичную сеть, то вы получите почти идеальную цифровую свободу — даже от того, что исследователи в области безопасности называют “глобальным противником.” Для некоторых подобный исход — это рай; для кого-то — скорее ад; в любом случае, он все ближе.
Что же разделяет “здесь” и “там”? Небольшие вопросы программного обеспечения. Несколько инженерных деталей. “Здесь” и “там” разделяют централизованные платформы ранних 2000-х, задавшие очень высокую планку качественного обслуживания, перескочить через которую децентрализованным (или даже всего лишь федеративным) системам очень тяжело. Управление своим сервером должно стать такой же простой задачей, как и управление своим Facebook-аккаунтом — сложная проблема, мягко говоря.
У централизации есть значительные технические преимущества. У децентрализации есть значительные социальные, экономические и политические преимущества. С 1980-ых маятник качнулся от Compuserve и AOL к персональным компьютерам и Интернету, и потом вернулся в изначальное положение. Наши кабельные модемы — это акустические модемы, а Facebook — диалап-сервис на мейнфрейме.
Кто угодно, кто в 1995 году предположил бы, что правильный путь реализации социальных сетей состоит в том, что весь мир должен просто подключаться к одному гигантскому мейнфрейму, был бы поднят на смех. Однако в этой ситуации мы и оказались, не так ли? Над Фултоном и братьями Райт тоже смеялись.
Но каждый, кто помнит 1995 год, помнит, как все это выглядело из 1985 года, года Compuserve и AOL. Тогда казалось, что новый децентрализованный мир был реален, и что все те CD-ROM, которые мы все еще получали по почте, были грустной, умирающей шуткой — игрушкой, которую мы переросли.
И так оно и оказалось. Возможно, наши платформенные драконы однажды разделят судьбу Озимандии. Впрочем, кто-то сначала должен их приручить…