Algorithmic Frontiers // Antonio Max

Share this post

RAMP - RoboNet Artificial Media Protocol

antoniomax.substack.com

RAMP - RoboNet Artificial Media Protocol

An HTTP/3 fork for AI media and systems.

Jun 5, 2023

Abstract. This working article presents RAMP (RoboNet - Artificial Media Protocol) a novel Internet protocol specifically designed to facilitate normative instrumentation for Internet's AI era, at a very low technical and political cost. The Protocol defines an operational distinction between artificially generated media and human made content by enforcing that some AI systems and specifically AI generated content, to no longer get served by the HTTP protocol, adopting as standard the newly proposed RAMP and its specifications instead. RAMP adoption offers a technical and legal framework for the offering of critical AI data, software and systems, while at the same time that it introduces a reliable industry-wide standard for AI provenance. RAMP aims to enable a future where individuals have enhanced agency on how they engage with AI data and systems, streamlining a more responsible engagement between AI service providers and Internet users.

Contents

1. Introduction
1.1. Why HTTP/3
1.2. RAMP instrumental capabilities
2. AI-generated content: A perspective
3. The non-RoboNet approach
4. RoboNet Artificial Media Protocol
4.1. RAMP’s vision for the near future
5. Content Provenance and Verification
6. Regulation and Standards
7. Challenges and Limitations
8. Conclusion
Annex 1 - RAMP and GenAI text challenges

1. Introduction

RAMP is an experimental Internet protocol built “on top” of the HTTP/3 IETF standard specifically introduced for serving most of AI generated content and AI systems that impersonate human behaviour (in a somewhat more encompassing terminology than “generative agents”,) with a focus on transparency and algorithmic accountability. The protocol is a response for a challenge of our times, and it aims to update the Internet itself as a response for its AI era.

The year of 2023 sets the bar for the last days of a World Wide Web (www) where the majority of the content inside it is still mostly “human made content”, and its digital counterparts arrive with many challenges regarding its cultural and intellectual integrity, authenticity and operational accountability. RAMP explores a novel approach to address the technical conditions that are the enablers for most of today’s Internet problems with AI, but it also impacts conditions that allows for misinformation, disinformation and content provenance conflicts to take place online, and RAMP offers a way to do so before the www becomes a place where the distinction between human and synthetically made content gets blurred forever.

Figure 1: Internet content reactive tendency

RAMP introduces an opportunity to address the reactive police-making imposed by the asynchronous feedback loop of AI’s innovation pace and the political-regulatory response to such pace. An Internet protocol specifically designed for AI is how RAMP’s unique vision introduces technical conditions that can empower uniform regulatory responses to emerge, so that modern society may engineer optimal strategies to welcome the deployment of worldwide AI’s systems.

An unique approach for AI regulation, RAMP targets AI services via its delivery method independently from its capabilities or features, features that can then be addressed at subsequent application stages, but then with the standardized provenance and compliance mechanisms provided by RAMP.

Figure 2: RAMP works “on top” of HTTP attaching its compliance mechanisms at AI service delivery phase, enabling optimal risk strategies

1.1. Why HTTP/3

While a custom and better tuned protocol would perhaps be the optimal choice in an ideal world, RAMP does not intent to enable a new functionality to the www itself nor it belongs to any proprietary software ecosystem that would justify a more exclusive set of capabilities, but what RAMP does intent, is to provide a future proof dual-use instrument, combining technical and regulatory instrumentation for the AI service delivery stack, and to best prove its capabilities it takes a highly unusual approach: it is basically an HTTP/3 clone, so that both initiatives can help each other succeed and accelerate their adoption by Internet industry stakeholders. Standards such as the HTTP don’t have many reasons to get cloned, but as RAMP aims to be as frictionless as possible on its first iteration, the use of HTTP/3 efficiency and up-to-date security practices as boilerplate, should offer all RAMP requires to grant regulators its instrumental advantages, “asap”.

Figure 3: HTTP protocol was left untouched for most of its life and 1.1 still stands

Standardized by the IETF as RFC 9114 in June 2022, the latest HTTP protocol update isn’t really new, the HTTP/3 has been around since 2016 and while it is slowly being adopted by Internet websites, 2023 browsers used by more than 70% of all Internet users already support its features and 30% of all human HTTP traffic in 2023 1st semester already uses it.

Figure 4: webpages tuned to use HTTP/2 features don't require changes to support HTTP/3 or RAMP. If your browser supports it, the images on this very article are delivered via HTTP/3 by the SubstackCDN service (image source: CloudFare radar)

HTTP/3 was 6 years in the making, by forking HTTP/3 standards in its initial phase, RAMP fast-tracks its adoption rate and also counts on the expertise of thousands of professionals who already have HTTP/3 experience. And a fork also offers the chance for a smoother transition over RAMP’s own evolutionary pace, so albeit rather unusual, the approach should be enough for RAMP initial aspirations. Chapter 4 elaborates further on how HTTP/3 paramount features empower RAMP’s unique approach to AI regulation.

1.2. RAMP instrumental capabilities

RAMP’s core practical function is to deliver this common language that can catalyze synthetic content regulations, AI standard developments, and friendlier AI stakeholder collaborations, as RAMP takes shape as this common instrument that isolates the technical language used to discuss AI’s delivery method, not its capabilities, in a moment where great AI professionals of all walks of life are asking for optimal political response for AI risks:

“Mitigating the risk of extinction from AI should be a global priority alongside other societal-scale risks such as pandemics and nuclear war.” - 2023, Center for AI Safety.

As RAMP overarching capabilities encompasses the entirety of the AI service delivery stack, it simplifies issues that are at the core of the international misalignment regarding shared AI regulations, as it addresses the lack of a common ground to target the misuse of AI technologies of today and tomorrow. And by being a distinct protocol, RAMP performs this role without impacting the HTTP Internet, a remarkably clean instrument for regulators.

http://info.cern.ch/hypertext/WWW/TheProject.html
Above: The first Internet webpage ever used http:// and is still online to this day

Same as the first internet webpage ever created by Sir Tim Berners-Lee on top of the HTTP protocol introduced the existence of every online service we have ever seen to date, modern collective knowledge of what these Internet protocols are capable should be the proper framing to assess RAMP’s own capabilities. RAMP is, without mistake, an unique historical opportunity on its own.

By working together with entities looking for modern AI best practices such as those focused on AI media metadata standards, like the International Press Telecommunications Council (IPTC) and the Coalition for Content Provenance and Authenticity (C2PA), RAMP enabled services can distribute synthetic media and AI systems as a compliance medium for AI industry standards, not as an intermediary, but as AI’s own digital delivery instrument, properly standardized for this end from its very start.

But above any implied end user benefits or technical capabilities that are indeed something to be largely explored, RAMP’s role is to become this instrumental catalyst for the regulation and standard developments of AI services, so that countries regulators, policymakers and other Standards Developing Organisations (SDOs) may finally share this common technical object that catalizes initiatives aimed at the several of the known and yet unknown AI technologies potential hazards, while also insulating today’s www Internet from massive waves of ad hoc AI oriented regulatory interventions, that are not only difficult to craft, but difficult to harmonize in the International Fora.

2. AI-generated content: A perspective

Given the recent developments of GenAI systems such as Stable Diffusion and ChatGPT, a remarkable amount of all our online systems are now exposed to the misuse of similar and new AI technologies that empower those using such appps with malicious intent, with capabilities yet to be properly understood. And while RAMP does not aim to provide an ultimate solution to all the old and new AI problems, its sharp focus on synthetic media and AI services delivery enables RAMP to interface with such issues before these may impact institutions, organizations and other ecosystems dynamics, giving RAMP a timely set of advantages over other regulatory approaches.

The following list samples two key implications of AI content and systems that arrive at distinct, non chronological moments of AI interactions lifecycle: the type* of issues and how* these are delivered;

The type of issues enabled by AI-generated media:

  • content that lacks watermarking or basic authorship consensus;

  • training data IP, copyright, fair use and licensing matters;

  • collection methods, source biases and information trustfulness;

  • alignment, control and misuse;

The how issues, as AI-generated content:

  • can be used to attack, corrupt and misuse legacy Internet services;

  • can impersonate biometrics such as voice or face and other credentials;

  • can automate misuse of data, techniques and credentials at scale;

  • can influence elections, media and social dynamics;

Figure 5: Left - Internet as is today with no protocol distinction for AI services Right: RAMP claims AI services leaving minimal AI overlap with HTTP services

RAMP aims to be both technologically and semantically inserted at the digital services stack as a proper delivery mechanism that catalyzes how AI services and content are exposed on the www along with the “legacy” HTTP, providing a clear legal instrument that allows targeted mitigation responses aimed at the AI issues stack.

3. The non-RoboNet approach

Recent American, Canadian and European developments on AI policymaking tackle major societal wide AI harms by using Risk Analysis principles as an holistic instrument in a very valid fashion, but treating AI traffic/apps/services/data as same as any other HTTP traffic comes with heavy societal-scale risks, that even with our ever improving regulations, means governments and citizens have to continue to rely on private sector companies and third parties to classify and moderate AI systems and content, demanding new sub-systems, procedures and institutional policies to tackle AI misuse at subsequent key moments of digital services lifecycles, in a particularly diffuse approach, where effective common governance mechanisms at global scale are virtually non existent and even live a moment of infighting for international influence in a standard setting warzone, where private sector and state-led AI governance initiatives going for "AI leadership", compete with non-state-led initiatives (here most notably OECD) and even SDOs such as ISO and the IEEE.

Laws, regulations and SMEs of all fields ask for content providers and platforms on the Internet to label synthetic media, to identify chatbots, to address disinformation posted and promoted by automated systems, create content filters for influence-as-a-service entities, address manipulative algorithmic systems, curb the use of deep fakes and AI-enabled disinformation operations. The ever growing list imposes costs at all operational levels for service providers and their counterparts /partners, with no industry wide established QoS standards, largely because same as the very problem list is new, the way societies react to it is pretty much the same age, in a domain where actual experts are a scarce resource, and forget lawmakers and politicians that can speak the field lingo with basic technical proficiency, always a painful watch.

And while common regulatory conformity mechanisms such as marked certifications may offer economic incentives for voluntary adherence on policies between economic allies, bad actors don’t share domestic or political benefits for any form of compliance, particularly in the defense industry, where the threats of cyberwarfare and digital espionage find even less reasons to play fair in Internet’s AI era. As an apolitical instrument as the HTTP itself, RAMP protocol is where compliance should, in the medium term, isolate non-compliant actors via simple peer dynamics.

4. RoboNet Artificial Media Protocol

While a real world Internet-Draft RAMP final specification may see different definitions than its experimental kin, RAMP allows the provision of AI media and systems without Internet users noticing anything different from everything they already do today. Same as HTTP/3 users don’t type http3:// on their browsers and apps when consuming HTTP/3 services, RAMP users won’t have to type ramp:// or ever even notice the difference from a regular HTTP service if nobody tells them. By operating at the protocol level, RAMP positions itself at Operational System (OS) level, which means every app and website and the very OS itself, are as transparently as possible, all aware of RAMP capabilities, features and standard.

Figure 6: Like HTTP/2 or 3, RAMP is still HTTP for end users, enabling access to AI services without using 'RAMP://' in the URL (note: not an OSI accurate graph)

As specified today, all RAMP requests implicitly have a protocol version of “5.0” while RAMP responses have 4 distinct versioning flavors: "5.10" for text/html content, "5.11" for mixed AI content, internally called RAMP1, "5.12" for RAMP2 or 100% synthetic content and AI automated systems and “5.0” for everything else, as defined in section 4.3.2 of the RAMP experimental RFC:

4.3.2.  Response Pseudo-Header Fields

   The following pseudo-header fields are defined for responses:

   ":status":  Carries the RAMP status code; see Section 15 of [HTTP].  
   This pseudo-header field MUST be included in all responses; 
   otherwise, the response is malformed (see Section 4.1.2).

   ":version":  Contains major and the minor version number. RAMP 
   responses implicitly have a protocol version of:
      "5.10" for text/html content,
      "5.11" for mixed AI content,
      "5.12" for 100% synthetic content and AI automated systems
      "5.0" is assumed for anything else as default.

      This pseudo-header field MUST NOT be empty for "http" or "https"
      URIs; A version component MUST include at least the value of 
      "5.0" as default.

The minor number is not meant to imply extra protocol capabilities, it is meant to offer straightforward content classification independently of status response numbers, so that OS level AI classification may be consumed at any RAMP implementation complexity, no matter how servers/proxies/gateways applications react to RAMP requests.

As an HTTP/3 fork, this article doesn’t further elaborate on its QUIC capabilities, how handshakes take place on first visits and apps, etc. Readers more interested on RAMP technical specifications might as well refer to specific HTTP/3 readings. Readers interested on following how the RAMP RFC evolves over time, you may compare RAMP and HTTP/3 specifications side by side using IETF iddiff tool.

Figure 7: Detail of an HTTP/3 and RAMP comparison

4.1. RAMP’s vision for the near future

By positioning itself at such key role on Internet’s own structure, RAMP understands the protocol have a part to play in the Internet’s ecosystem of devices and networks, so to better support its intentions, RAMP institutes 5 Core Principles:

  1. RAMP serves Mixed and 100% AI generated content only;

  2. RAMP serves all AI systems and services that provide human like behavior;

  3. RAMP service modelling should promote academic data cooperatives and trusts;

  4. RAMP content served by services using other protocols should be discouraged;

  5. RAMP compliance should have legal and/or binding regulatory incentives;

These principles are aspirational placeholders for industry wide standards, and are non vital for either RAMP deployment or even its voluntary compliance /certification by industry stakeholders, but they aim to offer optimal conditions for the use of RAMP’s many benefits and mechanisms along with other protocols.

And as an Internet protocol itself, RAMP offers additional instruments to address contemporary Internet perils such as the ones explored nowadays by those who misuse Social Media for the means of mass manipulation schemes, behavioral experimentation and informational hazards caused by the “traditional” and new disinformation “business” models.

On this, RAMP’s vision for the near future is that new impersonation businesses of the good type should eventually become something highly casual in modern online environments, particularly for personal assistant AI companies or even in distinct virtual locations such as the Metaverse, where AI powered NPCs acting as people may be an entire new business on its own. By adopting the RAMP2 as the proper delivery protocol for all types of automation businesses that explore legal impersonation techniques, optimal impersonation models and techniques should emerge within RAMP2 semantic conformity, isolating older (today’s) impersonation approaches on the HTTP to over time get detected by the ever so improving network analysis inspection tools, that today do work significantly better on HTTP/1.1 and HTTP/2 than on HTTP/3 and by proxy, on RAMP. RAMP believes in a future where its existence can help the Internet “patch” legacy friction points explored by those who exploit Internet’s structural weaknesses.

Figure 8: bots traffic detail according to Cloudfare traffic analysis implies yet to be seen challenges may be ahead for HTTP/2 and HTTP/3. RAMP provides a framework for even optimal mitigation strategies (image source: CloudFare Radar)

By joining the AI service delivery stack at protocol level, RAMP implementations such as those for industry OSs (today Android/iOS/Windows/Mac and Linux for most cases) should eventually become able to offer RAMP protocol provenance mechanisms as an end-user feature, here illustrated as a toggle button with 3 states:

Figure 9 - Conceptual RAMP Filter mock-up as an iOS like toggle button
  • HTTP/ON [only human content Internet]

  • RAMP1/Mixed [mix /composite human /AI content] [IPTC 1]

  • RAMP2/OFF [human, mixed and 100% digital content] [IPTC 1 - 2]

The middle /default option is there as equivalent to today's 2023 Internet, with no retroactive changes and Mixed AI generated content coming from RAMP1 services are served as default on this choice. The distinction between RAMP1 and RAMP2 media allows by side effect, other types of media to be understood as “human made”, not as empirically as desirable, but definitely in an approach that can be improved.

Such new conceptual features (Figure 7 ON and OFF states) can then treat RAMP’s traffic in a similar fashion to how any phone’s Airplane Mode toggle button works, which should eventually allow RAMP to in fact expose an Internet where people have the ability to make informed decisions on the type of AI content they want to consume in their apps and browsers.

And by forging mechanisms for such granular control to exist one day, RAMP’s aspirational intentions to safeguard future Internet generations from being exposed to poorly aligned AI developments can become a reality, RAMP’s ultimate goal.

5. Content Provenance and Verification

Guided by its core principles, RAMP updates the Internet specifically for AI so that the very Internet keeps up with the times, as emerging AI technologies don’t ask for permission to explore the pitfalls of legacy governance models in all places digital. RAMP distribution mechanism allows it to provide a clear content type distinction feature for how today’s AI systems offer their services, a distinction that may eventually even become an unavoidable necessity.

The benefits for bootstrapping RAMP architecture are many, e.g.: artists showing their art online can then have 2 proprietary streams to pitch their craft with the provenance mechanisms offered by HTTP and RAMP1 (for mixed authorship) all while 100% AI art is safely isolated at the RAMP2 access tier, so users browsing for art can safely identity what kind of artwork they are seeing. So at the same time that AI generated content provenance and authorship information gets isolated from its contents for both end users and websites serving them, AI distinction is available without relying on vendor-locked watermarking, content scanning schemes built by third parties, and other privacy threatening techniques, as RAMP Servers serve media with this type of classification at the protocol request’s “response header” level.

Figure 10: Left - A request for C2PA authenticity flow over an HTTP/1.1 application / Right - A RAMP request can return an IPTC friendly RAMP1 id two hops earlier

As RAMP provides transparent classification of AI content types getting served by applications at such earlier stage, RAMP promotes a resilient offering of specific types of AI data and systems, in a way that reduces the overhead to deliver specific propositions, such as specific apps that serve only 100% AI generated media.

Internet Servers understand the type of media they are serving, particularly those that are serving specific AI applications that generate AI media. RAMP doesn’t change how end users download images or music, but requires Servers — no matter the AI application they are serving — to be clear to Clients at the “response header” level if that response brings some mixed AI, AI systems or 100% AI generated media. This allows for plenty of technical room for sub classifications at application levels at the most distinct stages of “Alice X Bob” interactions. Further investigation on how having another RAMP version identifier such as "5.13" exclusively for the text generated by Large Language Models (LLMs) applications is required to better understand the relationship between provenance and privacy, but in theory identifying LLMs based applications traffic may offer opportunities for a broader ecosystem of apps that inspect or interact with this type of media. RAMP positions itself at the AI service delivery stack as an application agnostic requirement that in time should become fine tuned for compliance of most popular AI product types.

New standards for Generative AI media metadata are still largely unknown by the public, but Google, Midjourney and Microsoft already adopted IPTC /C2PA specifications for media generated by AI and the RAMP protocol can encapsulate these with its standardized provenance with zero friction, offering even more compliance mechanisms for digital assets consumption and training by AI systems, such as those specified by C2PA metadata, here sampled in CBOR diagnostic format:

// Assertion for specifying whether the associated asset and its data
may be used for training an AI/ML model or mined for its data (or both).

{
  "entries":
	"c2pa.ai_inference" : {
		"use" : "allowed"
	},
	"c2pa.ai_generative_training" : {
		"use" : "notAllowed"
	},
	"c2pa.data_mining" : {
		"use" : "constrained",
		"constraint_info" : "may only be mined on days whose names end in 'y'"
	}
}
Figure 11: Today’s data mining pipelines are analogous to common web browsing

As seen in Figure 11, when we look inside the hood of a scrapper engine crawling the www, Servers see not many distinctions from average browsing, user agents and other things come to rescue but Internet wise, nobody really watches what bots do or not as long as they don’t cross the barrier to be considered a treat, given that as far as definitions go, defining a bot characteristics and intentions can be vastly tricky.

Figure 12: An HTTP/3 request where a scrapper abides content metadata

HTTP/3 can do lots things better than its predecessors, including serving common HTML pages for scrappers. On Figure 12, a scrapper is configured to abide assets metadata “AI_inference” classification, for media that allows its consumption by AI inference use. Here RAMP goes a step further: it offers a chance for AI made and Mixed AI content to be served as such, a much more granular and particularly relevant classification that is specific for AI, on top of files metadata information:

Figure 13: RAMP responses can carry IPTC friendly AI media type classification, enabling granular AI/Non AI media consumption strategies / policies

With clear provenance distinction, trust can be broadcasted at protocol level so that Internet users may no longer need to rely on domestic laws or corporate policies to trust if a content is authentically human made or not, classification complexity is exposed on RAMP protocol response to Clients, that then can do as they please with that data. In such position, RAMP provides an unique opportunity for AI Service Providers to benchmark and build trust on AI systems, as its robust framework offers a much needed foundation for responsible and ethical practices, where Internet users should then enjoy a chance of no longer have to get exposed to artificial content or artificial systems by mistake or malicious intent. RAMP reframes ad hoc AI content provenance policymaking, so that Internet platforms such as those of Social Media apps can rely on RAMP’s up-to-date Standard to build their user experience upon, at the same time that regulators may then stop relying on same platforms as intermediaries for AI content classification.

Protocol distinctions between RAMP and HTTP/3 are the foundation on how AI regulation may then act on specific moments of AI lifecycle without impacting how the www is experienced by end users. More specifically, RAMP allows for both service providers and end customers to interact with RAMP services as a) Defined by RAMP standard specifications b) Defined by sovereign legal entities c) Defined at corporate or parental policies and d) Defined as end user setting; in this order. The reverse order of this list is how RAMP enables policymaking bottlenecks to exist at every stage of these interactions, as shown in the table below.

Figure 14: Above: RAMP AI provenance standard built-in compliance zoom / Table: RAMP built-in compliance enable policymakers and SDOs to interact at several specific moments of AI lifecycle deployments

Over time, RAMP independence from other protocols should expand the possibilities of what the many stakeholders can build with the protocol characteristics and behavior, allowing an entire set of solutions to be built atop of these capabilities, at both ends of RAMP interactions with other protocols. And as the understanding of how RAMP ecosystem behavior settles in, optimal protection mechanisms specifically oriented at security of AI data and systems have then RAMP’s proper delivery mechanisms to grow upon.

But where RAMP unexpectedly excels is that by being a distinct protocol for AI systems with OS level compliance capabilities, even offline AI systems can then abide to the device protocol policies, which safeguards that offline devices still abides to corporate, parental and user chosen settings regarding AI content, a paramount feature that no version of the HTTP protocol was ever designed to offer, as RAMP can work independently or not from devices Airplane modes.

Figure 15: RAMP multilayered capabilities for policies allow end-user devices in offline-mode to comply to offline policies no matter the app or website

Finally, there are likely even more complex and possibly unforeseen scenarios involving the misuse of AI in offline modes, particularly given that today's AI systems and apps network traffic have no distinction from those of any other type of app. By offering this enforceable* and distinct protocol, phones and computers OS settings can expose RAMP extra security layer for any apps, that without exposing user privacy or relying on online services, may in the future even enable authorities to use the RAMP to define geofencing policies that may completely disable the use of these AI systems in specific geographic areas, such as schools and prisons, even for offline sideloaded apps, a capability no technology or regulation currently available can offer or much less enforce. RAMP introduces the technical conditions that can enable such capabilities with virtually zero technological complexity to all vendors, streamlining a novel human centred security approach that while still imperfect, refines a method and common language for the discussion of these scenarios that simply does not need to impact Internet users on the “legacy” HTTP www on its AI specific interventions.

*Enforcing compliance won't address malicious users from compiling AI systems that bypass or disguise RAMP traffic in HTTP or similar, or even more advanced treats that are specifically engineered to bypass compliance and restrictions, but by having an entire protocol for the delivery of AI content and AI systems such as RAMP in place, offers this unique insight instrument for its traffic behavioral fingerprinting and for the training of algorithms and Firewalls or similar tools that can be used to enforce stronger assurances against the misuse of AI technologies — even under the most challenging scenarios — in an automation friendly approach.

6. Regulation and Standards

RAMP aims to enable a technical and regulatory instrument where the traffic of AI services may no longer hide its tracks whenever interacting with the www Internet by being more of common HTTP traffic noise. As the protocol itself handshakes other systems as as what it is, not as anything else, RAMP characteristics isolate AI from every other type of digital events, which simply renders RAMP as a powerful governance mechanism to all AI regulators, as RAMP offers an “AI off-switch” that is apolitical in nature, on top of all its features.

Not by accident, RAMP should be able to address common risks that arrive with the misuse of new AI systems built with no industry wide standards, as by having no common ground for targeting AI technologies, regulators impose AI content classification and detection on service providers technological choices, budgets and incentives for compliance. RAMP eliminates this step and the usual implications of its misuse such as biases and behavioral doctoring, as AI provenance is then no longer a matter of corporate detection, but a server side mechanism that can be enforced, audited and classified by domestic and international regulations and policies.

And if the day comes where conditions enable OS makers to adopt RAMP filter capabilities as described on Chapter 4.1, RAMP may then finally empower Internet users, and not corporations, to chose how Internet’s AI era may be consumed by them, as RAMP facilitates optimal conditions for mitigation strategies to be put in place to tackle the abuse and misuse of people’s www “public” data by today and tomorrow AI systems, at the same time that it enables a common technical framework for companies to expand on more adequate and standardized AI B2B practices.

As RAMP is a protocol that can deliver the distribution of human, mixed and synthetic media with standardized provenance, Internet Service Providers may also benefit from having two novel revenue streams that can deliver distinct and unique experiences for each of these business propositions, thanks to how RAMP automates provenance for these types of content. Over time, this business architecture should create the proper conditions to foster a less toxic and less geared by poor incentives Internet.

Figure 16 - RAMP protocol offers clear traffic distinction between HTTP and RAMP services/data while still providing the foundation for future AI use cases

As an Internet protocol, RAMP is also less exposed to domestic political frictions: As it is not a law, its definitions can remain technical in nature, removing the burden of asking for Social Media Platforms and Internet Service Providers to take a side on political stands regarding computational and artificial advantages of their home jurisdictions political moods for addressing AI misuse. Law may or may not enforce RAMP certification, Internet giants may or may not self regulate by adopting RAMP standards alongside HTTP/3 standards, these are all desirable political responses from regulators, SDOs and other stakeholders, not requirements for RAMP to be deployed nor adopted.

Also, to the best of my knowledge AI regulations, even the most recent ones such as the EU AI Act, are protocol agnostic, so RAMP still inherits legal provisions as fluidly as possible, but unlike a law, RAMP doesn't need to be sanctioned or not by Russia to work in Russian browsers, it is a software update and if countries decide to keep on regulating AI the same way as they already are, nothing needs to be changed.

RAMP aims to promote frictionless technical and legal characterizations for the delivery of AI systems and AI generated media, but by doing so at Internet protocol level, RAMP remains as apolitical as the very HTTP is, an instrument with valuable politico-regulatory benefits.

Lastly, RAMP allows for lawmakers and regulators to work on constitutional guidelines that cover the whole AI service delivery stack by targeting RAMP alone and how it engages with other Internet protocols or devices at the jurisdictions they’re at. RAMP empowers global AI policymakers to legislate specifically on AI by offering a common starting ground, leaving AI interactions with the www Internet as one of the many possible AI delivery and consumption methods that should eventually emerge, revealing RAMP as a valuable legal instrument for the future of AI.

7. Challenges and Limitations

Not even the HTTP/3 itself is that much of a popular chap, not many servers and websites use it at this moment and apparently the use of UDP instead of the TCP allows routers, switches, firewalls, data centers, networks and many other corporate environments to simply block UDP over ports 443 and 80 altogether, which by default makes requests downgrade themselves to HTTP/2 or even HTTP/1.1 versions, which ultimately negates all HTTP/3 benefits such as its speed or security. Tying RAMP to HTTP/3 adoption may accelerate industry compatibility and adoption for both, but that assumes a good amount of coordinated efforts, but this yes, may benefit everyone. The gist of this condition is that over satellites, networks, devices, Internet is this live wild interaction ecosystem of networks and devices that today have policies that play it safe by consuming mostly HTTP/1.1/2 Internet services, and HTTP/3 and RAMP are the future, that while still being vastly backwards compatible, can be “blocked” at various networks interaction stages, for non specific reasons. For what is worth, HTTP/3 was created because HTTP/2 could do better, and RAMP follows the same reasoning.

QUIC, the underlying technology empowering HTTP/3 (and by consequence RAMP as well) is much more secure for end users such as you and me, mainly because QUIC does not allow plain text (read insecure) communications to take place, everything is encrypted by default and apparently even TLS Proxy Firewalls to this day still can’t assess HTTP/3 data. This raises issues regarding compliance (specially in corporate networks,) and may even empower bad actors to chose HTTP/3 and RAMP as optimal delivery route for yet unknown treats. The upside is that everyone is safer, unfortunately, even bad actors.

RAMP also does not magically replaces Intellectual Property rights discussions, as RAMP is merely an encompassing asset that catalizes AI regulatory instrumentation by providing a common delivery asset for the matters of attribution, privacy and other legal dispositions such as ownership and licensing related to AI systems and AI media, it still a regulators job to work on better practices that put such mechanisms to use, same as still platforms job to clearly display RAMP provenance information. RAMP merely offers a common standard these parts can work over.

While AI traffic analysis own evolutionary pace tied to the AI traffic segmentation provided by RAMP may arguably eventually promote an ever so optimal ecosystem of security practices targeted at automated accounts and other methodologies that abuse and misuse digital services, it would be still be service providers job to address these, but RAMP fosters elements that allow stakeholders to share an even more powerful set of common security and compliance practices.

RAMP asks for Internet giant stakeholders not for a pause on AI developments, but for an opportunity to update the Internet itself for its AI era, as RAMP allows for a more consistent and encompassing approach that is human centered by design, one that is crafted for cooperation between AI providers, a proactive decision that acts as a building block for initiatives that look towards the fair and safe use of AI, a most needed foundation where the Internet then have a chance to grow with a plan.

RAMP updates Internet’s own structure, as shown in figures 17 and 18, so that users, companies and governments may enjoy optimal controls for AI on their devices.

Figure 17 - Without RAMP, the Internet may end up with AI services/clones in every aspect of our digital lives
Figure 18 - RAMP allows AI content and systems to have their own expression in their own particular space, in a way that allows Internet users to interact with AI content as they chose to, while preserving today's HTTP www as is

RAMP enables a valuable set of foundational technical assets aimed at addressing today issues related to how AI systems interact with Internet users in a prosocial approach, promoting a safer and more coherent online experience in the long term, it protects Internet users from geographically disconnected AI regulatory pace and the lack of optimal incentives Internet Companies and Services have budgeted for the misuse and abuse of their services. But that’s its limits, countries and their regulatory bodies would surely still face unintended consequences and challenges for their actions same as for their inaction, RAMP merely changes the dynamics, doesn’t eliminates problems.

Also, while RAMP presents a promising solution for addressing AI regulation and provenance, it is crucial to recognize that as a novel approach, ongoing research and collaboration are essential to refine and enhance its capabilities. RAMP should be treated as a technical instrument, similar to how HTTP is treated, focusing on its functional aspects rather than engaging in political debates. This approach ensures a safe and apolitical deployment of RAMP, enabling its full potential to be realized in promoting fairness, transparency, and accountability for the delivery of AI systems. By engaging in continuous research and collaboration, we can further develop and optimize RAMP, adapting it to the evolving landscape of AI technologies and regulations, and fostering an environment where the benefits of AI can be harnessed both responsibly and ethically by all.

Finally, RAMP empowers policymakers, regulators, scholars, and institutions to closely observe and analyze the behavior and evolution of the protocol itself. This unique perspective allows for a comprehensive understanding of how AI is collectively consumed worldwide. By embracing RAMP, these stakeholders can monitor the protocol's characteristics over time and gain valuable insights into the responsible deployment and usage of AI. RAMP enables AI systems to operate and evolve at their own digital pace, while providing the necessary framework for policymakers to shape regulations and foster a safer and more accountable AI ecosystem.

8. Conclusion

This article introduced RAMP as a dual-use technical-regulatory instrument where AI content origins can be reliably traced, verified and audited at its network delivery method, empowering Internet users and regulators to discern between AI-generated and human-created data and systems. By shifting the burden of AI content classification from Internet Service Providers internal technologies to an uniform global Internet Protocol standard, RAMP offers a novel approach for AI policymaking that can in fact deliver fairness, transparency, and accountability, all while granting semantic mechanisms that can better protect human rights and freedom of expression online. Provision of the RAMP protocol asks for small political synergy and regulatory effort towards its specification and deployment, but even so, it still ends up being a political and technical effort that is orders of magnitude smaller than orchestrating common and meaningful international regulations for today and tomorrow AI challenges. RAMP offers the Internet an unique set of benefits for its AI era, one that can be crafted and delivered for a relatively small political and temporal effort, that also imposes no cost and no impacts on Internet users everyday life.


Annex 1 - RAMP and GenAI text challenges

Disclaimer: RAMP is a protocol. It is meant to be a foundation where solutions can be built upon, RAMP is not a solution on its own. The HTTP enabled streaming services and online gaming to exist, it was the foundation for the whole e-commerce and now does it again by serving the entire Metaverse. Even after decades HTTP is still the bedrock for pretty much everything we see online. RAMP is HTTP for Internet’s AI era, so asking “what can RAMP do for us” may not the right question to ask. What I explore on this Annex is A response for one of the biggest challenges of Generative Artificial Intelligence, but as a protocol, RAMP limits lie at the hands of its users.

Disclaimer 2: This is an educational exercise that explores fictional scenarios to illustrate how the RAMP protocol features can change dynamics for the challenges imposed by Generative Artificial Intelligence misuse/abuse, particularly regarding plain text generation. While techniques explored in this Annex are based on real world concepts, services, brands and technologies to best illustrate RAMP capabilities, real world deployments ask for much more intimacy with the themes superficially covered here, this is not a cake recipe.

Introduction

This exercise introduces a method for provenance validation of text generated by Language Services offering Large Language Models (LLMs) or similar Generative Artificial Intelligence (GenAI) technologies for Internet users.

The RAMP protocol implement methods for content provenance by making sure files and systems served by RAMP Servers have a standard “response code” associated with metadata manifest data carried by these files or the AI services they provide. Texts generated by Language Services have no file were we can register this information on and this is a challenge many nice folks are trying to address in order to somehow enforce text provenance policies with these services.

According to RAMP principles, Language Services fall into its RAMP2 category as “systems that generate human like behavior” and as such, messages coming from RAMP compliant services should be using “RAMP/5.10” as version for its responses, but this Annex explores its “5.13” idea as mentioned in RAMP main article:

… further investigation on how having another RAMP version identifier such as "5.13" exclusively for the text generated by Large Language Models (LLMs) applications is required to better understand the relationship between provenance and privacy, but in theory identifying LLMs based applications traffic may offer opportunities for a broader ecosystem of apps that inspect or interact with this type of media. RAMP positions itself at the AI service delivery stack as an application agnostic requirement that in time should become fine tuned for compliance of most popular AI product types.

So to be clear, what RAMP does differently here is that provenance comes from RAMP compliant services at the delivery stage not in the application stage, meaning it is not apps or online services job to tell what is or isn’t a text generated by firms offering this as a product, this is RAMP’s provenance features in action, an apolitical and non “captured” instrument that by principle can deliver optimal privacy conditions at all stages of this Annex propositions.

The technical approach explored here is based on Apple’s controversial CSAM Detection technology and readers of its technical summary pdf document should have a chance to see a real world example of everything done here, understand the similarities and the overarching technical orchestration required to make it all work.

Apple’s approach was dependent not only in their own devices ecosystem, but also on its iCloud service as bridge to “detect” content at the same time that Apple devices sync with iCloud services for backups, stacking capabilities to existing services in order to avoid creating new “solutions/problems”. Both the target use of this technology and the way Apple sold this capability made the “feature” almost instantaneously go back to the drawing board, with Apple’s NeuralHash (Apple’s hashing function) ending up labeled as not ready for the prime time, as something that while efficient, was far from an ideal privacy friendly solution.

RAMP approach here also have dependencies but these do not invalidate the technique itself as it did for Apple, for analyzing the text generated by Language Services shouldn’t be as taboo as looking at people’s pictures. RAMP focuses on the text generated by Language Services with provenance granted by RAMP itself, no actual text people type on their devices is ever target of the concepts explored on this Annex, RAMP was designed to promote independent fairness and privacy and this exercise abides to these principles.

In full disclosure, one of my concerns about the approach explored here is about this central checking structure I named “Issues Centre” (sorry for the name, I just needed something somewhat exclusive). This is a place that somehow holds authority to send hashes to both Language Service providers and edge devices when the right set of conditions are met. While I perhaps should elaborate on this institution and its functions, this Annex isn’t about politics or AI regulation itself, so to keep things simple, this entity have only two more assumptions:

  • The type of institutions requesting check requests at the Issues Centre is an interesting asset to have, so that distinct approaches, practices and policies can be instated for the checking procedures, this should be handful for regulators. One of the possible instruments for such classification standards could be the UN International Standard Industrial Classification for economic activities (ISIC - Link), that can be used to identify industry specific types of requests with a standardized code. This concept is explored so that as in “Scenario 1”, only specific types of institutions may work with specific types of documents validation, so that function creep may be curbed;

  • The Issues Centre may only query edge devices after querying Language Service vendors with positive results, as a dual confirmation method as its core and only purpose;

How the Issues Centre query edge devices and other technical specifications about its capabilities are omitted. What follow are other assumptions required as worldbuilding assets.

Operational assumptions

Several assumptions are made to make this exercise work. In a nutshell, we are mostly talking about databases talking to each other, but real world deployments are packed with challenges that shouldn’t matter for now. If you believe otherwise, send me a message and I’ll update things here.

Generative AI text services

RAMP compliant Language Services only are assumed, which means these firms to be using "5.13" as version for its services responses to clients, no matter the platform.

It is also assumed these services have proper data retention policies in place, that would allow attribution to be credited to users abusing their services. There are many considerations on this topic alone but it is assumed this sector complies with their field policies and standards for both data privacy and data retention as well.

It is not assumed here that Language Services hold searchable records of their customers texts, but tokens, vector embeddings, semantic hashes or similar technologies are indeed a requirement for this architecture to work. Keep this in mind whenever “hash” or “hashes” are mentioned here.

Our main fictional Language Service firm is called LLM_Firm_1.

Databases

Three distinct databases are assumed: The ones that belong to Language services, a new one linked to edge devices OS and the one used by the Issues Centre.

It is wise to assume each of these to have particularities that should work as “sanity check” for this exercise. At first glance these are:

Issues Centre Databases:

  • Only members certified by authorities may add new records;

  • Database is available to registered members from all Countries;

Edge devices Databases:

  • Can’t be accessed/erased by users;

  • Users don’t know what’s in it or when anything was added;

These databases are populated with random, non linear, semantic hashes. Encryption is advised but nothing in these databases is intended to ever be reverse-engineered, this is not their purpose. A sample databse architecture may look like:

Technology overview

Each part takes ownership of their own databases and only under the correct circumstances it is assumed the Issues Centre Service have the means to communicate with parts databases.

Issue center interactions

Whenever a check request is filled, the Issues Centre adds it to its push list that is then submitted to certified Language Services. These services should receive a daily batch of distinct set of hashes or similar.

After some time, positive feedback should emerge among providers, so only then, singled providers start receiving Issues Centre attention for subsequent challenges.

After a sequence of random tokens gets indeed validated, it should be safe to assume that text came from some specific user account. Further inquiries can then be made on the edge device belonging to the author as double checking procedure for authorship but at this stage provenance have already been validated for that particular text with that particular provider.

Some would say: “Everything so far can be done without RAMP, so why bother?”.

RAMP provenance means only text delivered via its protocol to apps or websites may be added to these databases. This is true for both the Language Service providers themselves and people receiving their text/voice messages, as proposed edge device databases are managed by the OS not any app. Under RAMP standards, nothing the user types ever gets sent to any of these databases ever, period.

In HTTP there is no independent provenance trail for the OS to validate apps reporting about what should go or not into these databases, giving room for this capability to be exploited by malicious entities, and then it would be vendors and OS makers job to attribute provenance and these platforms already have too much decision power at their hands. RAMP can isolate Language Service texts at delivery method from all other types of Internet traffic and provide a privacy friendly alternative for the validation of Language Service generated texts no matter how and where they are used, and only that.

Validation scenarios

The following validation scenarios make use of this Annex technical assumptions to test its capabilities on validating if a simple text is or isn’t generated by known registered Language Services.

I’m not sure if these are the most politically correct examples nor if they are really really correct as I’m really stretching my all personal skills to orchestrate every cross-domain I’m touching here, so don’t be so hard on me, I’m just a guy.

Scenario 1

Alice cheats on her essay, almost half of it was generated by OpenAI’s ChatGPT and her professor expressed his sentiment to the board. After submitting the document for further inspection with the Issues Centre, a positive is indeed returned from a single vendor. It did not matter that Alice didn’t copied and pasted from the website into her essay, the validation takes random parts of the text that somehow also were present at that service’s own databases. After vendor confirmation, a second wave of hashes was also sent to Alice’s personal laptop that also confirmed the previous result, a double positive.

Scenario 2

Alice is having a breakdown and decided that embarrassing her ex Bob on his socials would make his new girlfriend bail and she has a plan to do so! She will post a racist message on his Twitter on his behalf. Alice is not really a racist too so she uses a “prompt hack” she found on Discord that makes a particular Language Service enter into a sort of “hater mode” and she does get her message indeed, a well crafted highly xenophobic sentence. But Alice knows that somehow these websites know when you copy their texts so she takes the pen and writes down word by word of what she sees on the screen so that later that day, she may send that from her ex phone while he is distracted by the game, the perfect plan she thought: “how would they know it’s generated if I’ll type it myself into someone else’s phone!”.

Alice succeeds and Bobs tweet ends up reported. This is a felony matter and Bob needs a lawyer now. Alice’s plan worked. Trying to prove the innocence of his client who never sent that text, Bob’s lawyer sends the suspicious tweet for analysis as probable fake/impersonation content:

Same as Apple’s approach, the techniques explored here are meant to enable capabilities without exposing user text or personal data to third parties, and while other important topics such as encryption were not even mentioned, I hope that RAMP capabilities and advantages explored here can help readers assess why RAMP can play a significant role for AI services of today and tomorrow, no matter the end user application, promoting safer interactions free from market players who could abuse or misuse AI safeguards.

Share
Comments
Top
New

No posts

Ready for more?

© 2023 Antonio Max
Privacy ∙ Terms ∙ Collection notice
Start WritingGet the app
Substack is the home for great writing

Our use of cookies

We use necessary cookies to make our site work. We also set performance and functionality cookies that help us make improvements by measuring traffic on our site. For more detailed information about the cookies we use, please see our privacy policy. ✖