The argument, in a few hundred words.
Give it a long article, an essay or a report. It returns what the page claims, what that claim rests on, and what it leaves out, with the source number on every point.
The document explicitly leaves out specific technical protocol mitigations, stating that mitigation techniques will change over time [1].Its own words, out of the run below.
One run, nothing edited.
The third heading is the one a summary usually skips: what the document leaves out.
Source 1: RFC 7258
what it claims
Pervasive monitoring is a technical attack on the privacy of Internet users and organisations that the IETF community must work to mitigate in protocol design where possible [1].
what it rests on
The document rests on technical discussions from the plenary meeting of the November 2013 IETF 88 meeting [[IETF88Plenary]] and exchanges on mailing lists including ietf@ietf.org and perpass@ietf.org [1]. It bases its definition of an attack on [RFC4949] from August 2007, referencing the diagram on page 24 regarding threats [1]. It relies on existing standards guidelines in [RFC3552] from July 2003, certificate transparency in [RFC6962] from June 2013, privacy threat models in [RFC6973] from July 2013, and architectural statements in [RFC1984] from August 1996 and [RFC2804] from May 2000 [1]. Publication rules are grounded in [RFC4844] from July 2007 and [RFC5741] from December 2009 [1]. Named individuals include authors S. Farrell and H. Tschofenig, along with Jari Arkko, Fred Baker, Marc Blanchet, Tim Bray, Scott Brim, Randy Bush, Brian Carpenter, Benoit Claise, Alissa Cooper, Dave Crocker, Spencer Dawkins, Avri Doria, Wesley Eddy, Adrian Farrel, Joseph Lorenzo Hall, Phillip Hallam-Baker, Ted Hardie, Sam Hartmann, Paul Hoffman, Bjoern Hoehrmann, Russ Housley, Joel Jaeggli, Stephen Kent, Eliot Lear, Barry Leiba, Ted Lemon, Subramanian Moonesamy, Erik Nordmark, Pete Resnick, Peter Saint-Andre, Andrew Sullivan, Sean Turner, Nicholas Weaver, Stefan Winter, and Lloyd Wood [1].
what it leaves out
The document explicitly leaves out specific technical protocol mitigations, stating that mitigation techniques will change over time [1]. It identifies a tension between mitigating pervasive monitoring and maintaining beneficial network management or anti-spam functions, but leaves unresolved how to balance them beyond asserting that an appropriate balance will emerge over time [1]. It relies on terms like "indiscriminate", "very large scale", "nefarious", and "benevolent" without providing technical definitions or threshold measures [1]. It asserts that legal and political aspects are outside the scope of the IETF, leaving unanswered how the broader Internet community should address them [1].
Source 2: RFC 8890
what it claims
When technical decisions present a conflict between the interests of Internet end users and other parties, the IETF should favor the interests of end users [2].
what it rests on
The document rests on historical precedent from [RFC0001] in April 1969, which urged easy use by a wide class of users, and the IETF mission statement in [RFC3935] from October 2004 [2]. It bases its technical architectural arguments on HTTP user agents defined in [RFC7230] from June 2014 and sandboxed execution environments, while citing Internet of Things systems as a counter-example [2]. It cites guidance from [RFC3724] from March 2004, [RFC6973] from July 2013, [RFC7258] from May 2014, [RFC7288] from June 2014, [RFC7624] from August 2015, [RFC7754] from March 2016, the ESCAPE workshop report in [RFC8752] from March 2020, and the paper [TUSSLE] from August 2002 [2]. It cites input from Edward Snowden at IETF 93 and the HTML5 Priority of Constituencies [2]. Named authorities include author M. Nottingham, IAB members Jari Arkko, Alissa Cooper, Stephen Farrell, Wes Hardaker, Ted Hardie, Christian Huitema, Zhenbin Li, Erik Nordmark, Mark Nottingham, Melinda Shore, Jeff Tantsura, Martin Thomson, and Brian Trammell, alongside Harald Alvestrand, Mohamed Boucadair, Joe Hildebrand, Lee Howard, Russ Housley, Niels ten Oever, Mando Rachovitsa, John Klensin, and Eliot Lear [2].
what it leaves out
The document explicitly leaves "negative impact on end users" undefined, leaving working groups to discuss and reach consensus on what constitutes harm [2]. It raises the problem of conflicting needs between different end users without defining a procedure to settle such conflicts beyond minimizing negative impact and designing for the pessimal environment [2]. It relies on concepts such as "better human society", "openness and fairness", and "social good" without providing objective standards for them [2]. It recommends consulting civil society organizations and user groups, but provides no formal mechanism to verify whether those groups accurately represent end users [2].
- [1]https://www.rfc-editor.org/rfc/rfc7258.html
- [2]RFC 8890https://www.rfc-editor.org/rfc/rfc8890.html
Command in, answer out.
The lines in the middle are the agent reading. Each one names a page, what it weighed once the markup was gone, and where it came from.
### Source 1: RFC 7258 #### what it claims Pervasive monitoring is a technical attack on the privacy of Internet users and organisations that the IETF community must work to mitigate in protocol design where possible [1]. #### what it rests on The document rests on technical discussions from the plenary meeting of the November 2013 IETF 88 meeting [[IETF88Plenary]] and exchanges on mailing lists including ietf@ietf.org and perpass@ietf.org [1]. It bases its definition of an attack on [RFC4949] from August 2007, referencing the diagram on page 24 regarding threats [1]. It relies on existing standards guidelines in [RFC3552] from July 2003, certificate transparency in [RFC6962] from June 2013, privacy threat models in [RFC6973] from July 2013, and architectural statements in [RFC1984] from August 1996 and [RFC2804] from May 2000 [1]. Publication rules are grounded in [RFC4844] from July 2007 and [RFC5741] from December 2009 [1]. Named individuals include authors S. Farrell and H. Tschofenig, along with Jari Arkko, Fred Baker, Marc Blanchet, Tim Bray, Scott Brim, Randy Bush, Brian Carpenter, Benoit Claise, Alissa Cooper, Dave Crocker, Spencer Dawkins, Avri Doria, Wesley Eddy, Adrian Farrel, Joseph Lorenzo Hall, Phillip Hallam-Baker, Ted Hardie, Sam Hartmann, Paul Hoffman, Bjoern Hoehrmann, Russ Housley, Joel Jaeggli, Stephen Kent, Eliot Lear, Barry Leiba, Ted Lemon, Subramanian Moonesamy, Erik Nordmark, Pete Resnick, Peter Saint-Andre, Andrew Sullivan, Sean Turner, Nicholas Weaver, Stefan Winter, and Lloyd Wood [1]. #### what it leaves out The document explicitly leaves out specific technical protocol mitigations, stating that mitigation techniques will change over time [1]. It identifies a tension between mitigating pervasive monitoring and maintaining beneficial network management or anti-spam functions, but leaves unresolved how to balance them beyond asserting that an appropriate balance will emerge over time [1]. It relies on terms like "indiscriminate", "very large scale", "nefarious", and "benevolent" without providing technical definitions or threshold measures [1]. It asserts that legal and political aspects are outside the scope of the IETF, leaving unanswered how the broader Internet community should address them [1]. --- ### Source 2: RFC 8890 #### what it claims When technical decisions present a conflict between the interests of Internet end users and other parties, the IETF should favor the interests of end users [2]. #### what it rests on The document rests on historical precedent from [RFC0001] in April 1969, which urged easy use by a wide class of users, and the IETF mission statement in [RFC3935] from October 2004 [2]. It bases its technical architectural arguments on HTTP user agents defined in [RFC7230] from June 2014 and sandboxed execution environments, while citing Internet of Things systems as a counter-example [2]. It cites guidance from [RFC3724] from March 2004, [RFC6973] from July 2013, [RFC7258] from May 2014, [RFC7288] from June 2014, [RFC7624] from August 2015, [RFC7754] from March 2016, the ESCAPE workshop report in [RFC8752] from March 2020, and the paper [TUSSLE] from August 2002 [2]. It cites input from Edward Snowden at IETF 93 and the HTML5 Priority of Constituencies [2]. Named authorities include author M. Nottingham, IAB members Jari Arkko, Alissa Cooper, Stephen Farrell, Wes Hardaker, Ted Hardie, Christian Huitema, Zhenbin Li, Erik Nordmark, Mark Nottingham, Melinda Shore, Jeff Tantsura, Martin Thomson, and Brian Trammell, alongside Harald Alvestrand, Mohamed Boucadair, Joe Hildebrand, Lee Howard, Russ Housley, Niels ten Oever, Mando Rachovitsa, John Klensin, and Eliot Lear [2]. #### what it leaves out The document explicitly leaves "negative impact on end users" undefined, leaving working groups to discuss and reach consensus on what constitutes harm [2]. It raises the problem of conflicting needs between different end users without defining a procedure to settle such conflicts beyond minimizing negative impact and designing for the pessimal environment [2]. It relies on concepts such as "better human society", "openness and fairness", and "social good" without providing objective standards for them [2]. It recommends consulting civil society organizations and user groups, but provides no formal mechanism to verify whether those groups accurately represent end users [2]. Sources [1] https://www.rfc-editor.org/rfc/rfc7258.html [2] RFC 8890 https://www.rfc-editor.org/rfc/rfc8890.html
The URL of one long article, essay, post or report. Several are allowed, and each one gets its own summary.
- https://www.rfc-editor.org/rfc/rfc7258.html
- https://www.rfc-editor.org/rfc/rfc8890.html
The argument in a few hundred words in three parts: what the page claims, what it rests on, and what it leaves out, with the source number on every point.
By hand this is an hour of reading and a summary that quietly keeps whatever you already believed.
The command that produced all of this.
Paste it as it is and watch it work, then swap in your own pages. With your Lyrenth key set, it prints the finished prompt and its numbered sources, ready for whichever assistant you already use. Point it at an OpenAI-compatible endpoint and it answers on its own, the way the run above did.
Table from pages
Give it several similar pages and get one table, a row per page, with an empty cell wherever a page did not say.
See what it does →Terms in plain English
Get terms of service or a privacy policy in plain English, with the clause behind every point.
See what it does →Who works there
Read a company's own team and careers pages and get who works there and what they are hiring for.
See what it does →