Internet Draft Category: Informational Meng Weng Wong, pobox.com draft-ietf-marid-rationale-00.txt Expires: September 2004 June 2004 Behind The Curtain: An Apology for Sender ID Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire in September 2004. Abstract The architecture of Sender ID follows from a set of design decisions. Those decisions were motivated by philosophical, engineering, and political considerations. This document reviews some of the important choice that distinguish Sender ID from alternative possibilities in the same space. Wong [Page 01] Internet-Draft Sender ID Rationale Jun 23 2004 Table of Contents 1. The Aspen Framework 2. Two Cultures Of Authentication 3. Architectural Considerations 4. Design Goals and Guidelines 4.1 Design Goals 4.1.1 Fast widespread adoption. 4.1.2 Minimizing friction. 4.2 Design Guidelines 4.2.1: optimize for ease of publishing over ease of implementation. 4.2.2: follow the path of least resistance. 4.2.3: Find a middle way by setting mechanism, not policy. 5. Life Cycle Design 6. Choices reflected in Sender ID's Architecture 6.1. Identity 6.1.1. Am I MTA or Not? 6.1.2. Am I an MTA for the HELO domain? 6.1.3. Am I an MTA for the MAIL FROM domain? 6.1.4. Am I an MTA for the responsible sender according to the 2822 headers? 6.1.5. Why use SUBMITTER instead of the HELO name? 6.2. Per User Lookups 6.3. Response Codes 6.4. Block or Factored 6.5. Set-theoretic or Procedural 6.6. Record Type 6.7. Record Syntax 7. Business Analyses 7.1. Economic Analysis: Market failure and collective action 7.2. Marketing Analysis: Chasm Theory 7.3. The need for coordinated deployment. Normative References Informative References Author Wong [Page 02] Internet-Draft Sender ID Rationale Jun 23 2004 ---------------------------------------------------------------------- 1. The Aspen Framework ---------------------------------------------------------------------- Sender ID fits into a larger framework which was devised at a conference held at the Aspen Institute in December 2003. That framework has these parts: 1) authentication 2) accreditation 3) reputation Authentication tries to answer the question: "How confident can a receiver be that an email message really is from who it claims to be from?" It counters forgery and fraud. Accreditation lets third parties vouch for senders with whom they have a prior relationship. Reputation systems help receivers decide the disposition of incoming messages. Reputation systems rate senders and their accreditors. Receivers may develop local reputation systems, employ third party reputation services, trust certain accreditors directly, or do all of the above. The absence of prior trust between arbitrary senders and receivers implies a potentially skeptical relationship between accreditation and reputation services. This framework resonates with real-world models of human interaction. For example, reputation services exist today in the form of credit bureaus and movie reviews. Accreditation services exist today in the form of passports and university diplomas. Sender ID directly enables authentication and accreditation, and indirectly supports reputation technologies. Wong [Page 03] Internet-Draft Sender ID Rationale Jun 23 2004 ---------------------------------------------------------------------- 2. Two Cultures Of Authentication ---------------------------------------------------------------------- Sender ID provides syntax and semantics that help answer the authentication question: "How confident can a receiver be that an email message really is from who it claims to be from?" But there are at least two ways to ask and answer the question. In a designated sender scheme, the question becomes: "is the SMTP client of an incoming message authorized by the purported sender of that message to send the message?" The primary identity is the sender of the message --- the (administratively independent) entity responsible for the most recent injection of the message into the mailstream. Designated sender schemes consider the channels through which a message is transported. They do not consider the content of the message. In a store-and-forward model of email, designated sender schemes apply to hops between administratively independent domains. In a cryptographic scheme, the question becomes: "do the credentials embedded in the message validate its purported authorship, according to a public-key cryptosystem?" The primary identity is the author of the message --- the entity which created the content. Cryptographic schemes consider the content of a message. They do not consider the means by which it was delivered. Cryptographic schemes are congruent with an end-to-end model of email. Note that designated sender schemes are generally better suited to identifying senders and cryptographic schemes are better suited to identifying authorsship. Sender ID defines mechanisms that implement a designated sender scheme. Sender ID can also be extended to describe cryptographic schemes. Wong [Page 04] Internet-Draft Sender ID Rationale Jun 23 2004 ---------------------------------------------------------------------- 3. Architectural Considerations ---------------------------------------------------------------------- The greatest virtue of Internet email is openness. Open systems suffer the problem of abuse. Sender ID tries to curtail domain spoofing as much as possible while encroaching upon virtues as little as possible. It does this by aiming for mechanism, not policy. A number of competing requirements inform the design. On the one hand, position A is valid; on the other, so is position B. - Zombies versus hobbyists. - Spam folders versus SMTP rejects. - Rejecting before DATA vs rejecting after DATA. - 100% backward compatibility versus an unacceptable status quo. - Nipping the innocent in the bud. - Inconveniencing non-participants. - The perfect is the enemy of the good. - There is no such thing as an interim standard. - This is a job for sysadmins. - DNS: Caching versus parsing. - DNS: speed vs expressiveness. - DNS: ease of writing vs ease of reading. - DNS: use of XML vs development of a little language. Zombies versus hobbyists: A - A majority of spam today originates from end-user machines infected by viruses that send spam directly to receivers' MX servers. Such zombies should no longer be able to send direct-to-mx spam. B - Linux hobbyists should still be able to send mail from their consumer-grade broadband connections. They may have no control over the PTR records of their assigned IP addresses, but the concept of first-class and second-class citizenship rankles many idealists who believe in an unfettered end-to-end model of pure IP connectivity. Spam folders versus SMTP rejects: A - Rejecting messages at SMTP time is too abrupt. Filing to a spam folder is better; that way, recipients have a chance to pull false positives back from the brink without embarrassment. Wong [Page 05] Internet-Draft Sender ID Rationale Jun 23 2004 B - Filing to a spam folder often means nobody sees a message, and false positives silently disappear. If a sender receives no notification that a message was lost, the integrity of the email system suffers. Rejecting before DATA vs rejecting after DATA. A - If the protocol makes spoofs rejectable before DATA, we save bandwidth. We can even honour per-user policies. B - If the protocol rejects spoofs only after the message DATA has been received, we have the opportunity to review the message content in greater detail. 100% backward compatibility versus an unacceptable status quo: A - the Old Email is broken in many ways, and spam will continue to be a problem until it is fixed. B - the New Email should be 100% backward compatible with the Old Email, and nobody should have to change anything for the New Email to work. Nipping the innocent in the bud: A - Spam should be stopped before it starts; to limit the cost of a spam attack, receivers should by default adopt a skeptical stance to any unknown input. In big cities, people don't talk to strangers. B - In small towns, people smile at strangers. Senders should be assumed innocent until proven guilty. Any person should be able to get onto the Internet, register a domain, and immediately email a hundred of his closest friends. Inconveniencing non-participants: A - The designated sender model works correctly for the vast majority of all mail, which is sent directly from sender to recipient. In its strong form, Sender ID permits rejection of unwanted mail before the DATA command; this represents a significant bandwidth savings. Under the designated sender model, the strategy that minimizes the global amount of work requires non-conformant sites (primarily, forwarders and web-generated emailers) to work toward conformance (ie. Pre-pending headers and adding SUBMITTER support Wong [Page 06] Internet-Draft Sender ID Rationale Jun 23 2004 B - Forwarders and web-generated emailers are merely operating according to time-honoured traditions. Sender ID changes the terms of their unwritten contract; it is unfair to demand that they change. Placing the good of the many above the good of the few can lead to a tyranny of the majority. The perfect is the enemy of the good: A - people who are losing money every day due to spam want the New Email to be done quickly. B - people who worry about the overall architectural integrity of the Internet want the New Email to be done right, even if that takes longer. There is no such thing as an interim standard: A - it is important to experiment with new protocols on a large scale before officially blessing anything. B - there is no such thing as an "interim" standard: anything that rolls out at all will be there forever. Perhaps this conflict can be solved by moving to a "controlled burn" model of change management on the Internet. This is a job for sysadmins: A - the New Email should be fully transparent to the end-user and require no reconfiguration. B - no disagreement! DNS: Caching versus parsing. A - To reduce the burden on clients, records should be easily cached. Records that describe the full set of designated senders up front are easily cached and require no subsequent lookups. However, such records require parsing. B - To reduce the burden on clients, records should require minimal parsing. Records that answer "yes/no" for a given query aganst a domain/IP tuple can be easily parsed using existing DNSBL logic. However, such records are not easily cached, particularly when a wide range of IP addresses produce multiple negative results. Wong [Page 07] Internet-Draft Sender ID Rationale Jun 23 2004 DNS: speed vs expressiveness. A - The protocol should minimize the number of DNS queries needed, particularly serial queries. This reduces start-to-finish time. B - The protocol should be rich and expressive, even if that means multiple lookups are needed to resolve an answer. This increases start-to-finish time. DNS: ease of writing vs ease of reading A - it should be easy for senders to publish records. Maybe senders should describe their designated sender policies in a high-level form and leave correct interpretation up to the receivers. If they change an MX server's IP address, Sender ID should be smart enough to do the right thing automatically. The whole point of the DNS is to map symbolic names to lower-level data. Unnecessary redundancy is undesirable. B - It should be easy for receivers to query records. Maybe senders should be expected to precompile designated sender information into a canonical form. Every time an MX server changes its IP address, it's the sender's job to remember to republish the designated sender data. DNS: use of XML vs development of a little language A - The syntax should be easy for receivers to implement. The adoption of existing data formats such as XML means that existing libraries can be used to parse the data. XML is popular among the Microsoft community. B - The syntax should be easy for receivers to implement. The use of a custom-made little language means that heavyweight XML libraries are not required. XML is generally unpopular among the open community. Wong [Page 08] Internet-Draft Sender ID Rationale Jun 23 2004 ---------------------------------------------------------------------- 4. Design Goals and Guidelines ---------------------------------------------------------------------- This section discusses a way to broadly measure the success of the project. It also lays out the design philosophy which guides decision-making. * Market-based metrics. Sender ID is not the only specification to take aim at the problem of authentication. Other designs reflect different goals. Some designs are within the LMAP family (eg. DMP, RMX). Other designs are not (Call-Back Verification, Challenge/Response). With a variety of designs on the market, the success of this effort can be measured by relative market share; how many domains publish Sender ID records, and how many receivers check them? * The Fax Effect The value to a domain of adopting the standard depends, in part, on the number of other domains who have already adopted the standard. This is commonly called the fax effect: the first two people to buy a fax machine could only use it to communicate with each other, but every subsequent adopter could use it to communicate with everybody else who already had one. Today, faxes are everywhere. Sender ID represents a major shift in the paradigm of email. For the fax effect to fully manifest, a significant majority of legitimate email on the Internet should be covered by Sender ID. 4.1 Design Goals The design goals follow logically. Wong [Page 09] Internet-Draft Sender ID Rationale Jun 23 2004 4.1.1 Fast widespread adoption. To get the fax effect on our side quickly, we want to make it possible for people to quickly and easily adopt the standard. On the publishing end, this meant that the syntax and semantics must be easily learned by busy people whose level of DNS technological savvy we could not take for granted. Alternatively, a wizard can help them set up records which they can treat as opaque. On the receiving end, this meant that the standard should be reasonably straightforward to implement for the most popular MTAs. There are many more sender domains than receiving MTA implementors. Therefore, the design should optimize for ease of publishing over ease of implementation. 4.1.2 Minimizing friction. Even the least amount of friction will impede adoption. The Design should take advantage of existing capabilities wherever possible. The design should optimize for the path of least resistance. The less overhead needed to publish a record, the better. 4.2 Design Guidelines The design guidelines that result from the above goals are: 4.2.1: optimize for ease of publishing over ease of implementation. 4.2.2: follow the path of least resistance. 4.2.3: Find a middle way by setting mechanism, not policy. Where design alternatives appear to conflict, find a technical compromise that lets each school operate; do not mandate or prohibit any of the choices. Wong [Page 10] Internet-Draft Sender ID Rationale Jun 23 2004 ---------------------------------------------------------------------- 5. Life Cycle Design ---------------------------------------------------------------------- The designed protocol is a thing that does not stand in isolation, but moves through a life cycle; to be successful, it must be pass both economic and marketing muster at each stage in its life. Cautious people will want to transition gradually toward full acceptance of Sender ID. Therefore Sender ID cannot be designed with only on/off states; it should have a transitional adoption strategy. Over-specifying the protocol leads to untimely ossification. Under-specifying the protocol leads to a lack of expressiveness. The solution to both over-specification and under-specification is to ensure extensibility. Extensibility should be well defined on both syntactic and semantic levels. A well-designed protocol often finds itself being legitimately used in ways the original designers did not anticipate. Unexpected uses validate the expression model. To date, a number of unexpected uses have arisen: for example, use of the "exists" mechanism to perform basic logging. ---------------------------------------------------------------------- 6. Choices reflected in Sender ID's Architecture ---------------------------------------------------------------------- Given the above architectural considerations, design goals, and design guidelines, Sender ID makes a number of choices. ---------------------------------------------------------------------- 6.1. Identity ---------------------------------------------------------------------- Authentication schemes can focus on a number of identities. The simplest schemes ask if the IP address of the SMTP client should be permitted to send mail or not. More complex designated sender schemes add a domain-name dimension. They ask if the IP address is permitted to send mail *for that domain*. Wong [Page 11] Internet-Draft Sender ID Rationale Jun 23 2004 6.1.1. Am I MTA or Not? The simplest scheme asks a network owner if a given IP address is allowed to send mail to the public Internet. Instances of this scheme include: - .mxout. - MTAMark - Selective Sender Such schemes generally store the permission information in the PTR tree, alongside it, or in a parallel domain tree. These schemes make the "zombies versus hobbyists" tradeoff in favour of blocking zombies. If we assume that a hobbyist has no control over their PTR record, and will have no control over their MTAMark/SS/.mxout. record either, these schemes disenfranchise hobbyists. In accordance with its "mechanism, not policy" design philosophy, Sender ID makes the "zombies versus hobbyists" tradeoff in favour of hobbyists who are assumed to control the forward DNS of a domain they own. The important thing is to establish accountability: if a spammer wishes to designate a zombie as a permitted sender, the message is Sender ID conformant; it is the responsibility of the reputation system to reject the message. 6.1.2. Am I an MTA for the HELO domain? The next simplest scheme asks the domain of the HELO command if the IP address is a permitted sender for that domain. - DRIP - CSV Authenticating the HELO identity is useful for whitelisting by MTA hostname. Reputation services could evaluate relays identified in the HELO domain. Wong [Page 12] Internet-Draft Sender ID Rationale Jun 23 2004 6.1.3. Am I an MTA for the MAIL FROM domain? Schemes that ask this question include: - DMP - RMX - FSV - DVP - SPF DMP allows the HELO domain to override the MAIL FROM. SPF uses the HELO domain only when the MAIL FROM is null. Using the MAIL FROM address is considered useful for fighting joe-job bounce blowback, but it has the disadvantage of requiring forwarders to use some sort of return-path rewriting scheme and thereby become transport remailers. Paul Vixie alluded to this in his 2002 paper. 6.1.4. Am I an MTA for the responsible sender according to the 2822 headers? It is useful to use Designated Sender techniques to validate sender information seen in the MUA. If conforming mailers prepend an appropriate header to indicate a relay hop, MUAs can extract a Purported Responsible Address (PRA) from the headers and display that information. The SUBMITTER parameter to MAIL FROM is a preview of the Purported Responsible Address from the 2822 headers. If present, it overrides MAIL FROM. Using 2822 sender information is considered useful for fighting phishing. However, it requires that MUAs display both author and sender information. Outlook already does this, with "from X on behalf of Y". Other MUAs who wanted to use the benefits of 2822 Sender ID authentication would have to also display "from X via Y" information. If a message was forwarded through multiple hops, it may be necessary to display "from X via Y via Z". In the simple legitimate case, the Purported Responsible Address would be the "From" header, and there would be no "Sender" or "Resent-From" type headers. MUAs might be able to mark mail from certain domains Wong [Page 13] Internet-Draft Sender ID Rationale Jun 23 2004 with a "trusted" hint. In a phishing attempt, spoofs would lack the "trusted" hint. The "trusted" hint would also be missing in a message sent through a forwarding system, but presumably the end-user would know what messages were forwarded, and adjust their expectations accordingly. 6.1.5. Why use SUBMITTER instead of the HELO name? Promoting the Purported Responsible Address into the MAIL command provides two benefits: it makes it possible to reject spoofs before DATA, and it potentially makes adoption easier for forwarders. The HELO name may still be authenticated using an SPF check; however, it is not the subject of this document. ---------------------------------------------------------------------- 6.2. Per User Lookups ---------------------------------------------------------------------- Doing per-user lookups reduces cacheability but increases granularity. Per-user lookups can be supported all of the time, some of the time, or none of the time. Sender ID chooses to support per-user lookups some of the time using the "exists" mechanism, with the expectation that only low volume senders will use this feature; therefore the burden on DNS is believed to be acceptable. ---------------------------------------------------------------------- 6.3. Response Codes ---------------------------------------------------------------------- The simplest scheme has only two response codes: good or bad. More complex schemes expand the set of responses to good, bad, and unknown. In response to criticism from Steve Bellovin , Sender ID provides a range of seven response codes. Wong [Page 14] Internet-Draft Sender ID Rationale Jun 23 2004 "Error" and "Unknown" correspond to temporary and permanent failures. "Neutral" indicates the queried domain explicitly wishes to pretend it does not publish Sender ID records. "None" indicates the queried domain does not, in fact, publish Sender ID records. "Pass" means the administrator of the sender's domain states that the message comes from an IP address assigned to one of that domain's authorized outbound e-mail servers. "Fail" means the administrator of the sender's domain states that the IP address from which the message was received is not assigned to one of that domain's authorized outbound e-mail servers. "Softfail" indicates a transitional state: while not as strong as "fail", it means the administrator of the sender's domain states that the IP address from which the message was received is not assigned to one of that domain's authorized outbound e-mail servers, however, the message may still be legitimate. Receivers should treat it with skepticism. This has significance for spam scoring systems. The adoption path is greatly smoothed by the presence of "softfail" as a standard result code. ---------------------------------------------------------------------- 6.4. Block or Factored ---------------------------------------------------------------------- In a purely block-style protocol, published records completely describe the sets of designated senders. Receivers are expected to figure everything out based on those records. Receivers only need to fetch information from senders the first time a query occurs; subsequent fetches can be retrieved from the DNS resolver cache or from a nearer application cache. In a purely factored-style protocol, receivers include pertinent information in the DNS query; sender servers are expected to return a response based on those inputs. While the parsing burden tends to be lower with factored-style protocols, receivers need to perform a DNS lookup for each new IP client for that domain. Large receiving sites tend to prefer the block style because it avoids repeated lookups; for efficiency they can also transform the block records into an internal representation that is locally cached and distributed. Wong [Page 15] Internet-Draft Sender ID Rationale Jun 23 2004 Specifications which use purely factored-style records are not transformable. They include MTAMark, SS, DVP, and DMP. Specifications which use purely block-style records are fully transformable. They include Caller-ID and RMX. FSV offers both block and factored record styles. Sender ID is largely a block-style protocol but provides for factored lookups using the "exists" mechanism. Sender ID is therefore partly transformable. Publishing domains which refrain from using "ptr", "exists", and per-user macros can be cached. Most high-volume senders are expected to publish data in IP-only notation as a courtesy to receivers. Noncacheable mechanisms are therefore expected to be used only by smaller sites. This is considered an acceptable tradeoff. ---------------------------------------------------------------------- 6.5. Set-theoretic or Procedural ---------------------------------------------------------------------- Block-style declarations can be further expressed in two ways: set-theoretic or procedural. In a set-theoretic scheme, publishers explicitly partition the input space into result codes. Receivers locate the input tuple in that space and return the result. In a procedural scheme, publishers provide an ordered list of mechanisms which are evaluated sequentially. The first mechanism to match determines the result. With the exception of the "exists" mechanism, the procedural scheme can be mapped to a set-theoretic representation. The two schemes are therefore isomorphic except when "exists" is used. ---------------------------------------------------------------------- 6.6. Record Type ---------------------------------------------------------------------- Several alternatives are possible: * new, custom RR type. * TXT record. * record with underscore subdomain. The record type is still being decided. Wong [Page 16] Internet-Draft Sender ID Rationale Jun 23 2004 ---------------------------------------------------------------------- 6.7. Record Syntax ---------------------------------------------------------------------- Two alternatives include: * Ad-hoc SPF notation * XML Receiver systems should not have trouble supporting both using a "two parsers, one interpreter" model. The ad-hoc SPF notation has been specified and field-tested, and is not expected to change. The XML representation is presented in the marid-core document. Sender ID will be compatible with both. ---------------------------------------------------------------------- 7. Business Analyses ---------------------------------------------------------------------- Where deployment and adoption are concerned, business and marketing considerations are as important as technical considerations. 7.1. Economic Analysis: Market failure and collective action To successfully deploy, the New Email requires significant resource allocation: at the minimum, it needs implementation labour, interoperability testing, and a big, expensive, PR campaign. Given the amount of work that needs to be done, a single organization is unlikely to create a pure public good at its own expense. On the multinational Internet, this is as true when the organization is a corporation as when the organization is a state. The technical name for this problem "market failure", though it encompasses the absence of government provision as well. Intellectual property rights over the developed standard are one way out of the market failure problem. However, the public's distaste for kingmaking reduces the chances of successful adoption of any licensed technology. Economically speaking, market failure in this case is solved by collective action by major ISPs. A mechanism that reduces the existing cost of imperfect spam filtering will be adopted and evangelized by ISPs who bear that cost. Wong [Page 17] Internet-Draft Sender ID Rationale Jun 23 2004 7.2. Marketing Analysis: Chasm Theory The designed product, and the augmentations that surround it, must survive each phase of Geoffrey Moore's Chasm model. The core specification should be attractive enough to the visionaries to seed the fax effect by publishing records and writing libraries. After an initial round of discovery and experimentation by the early adopters, the mainstream must be encouraged to start publishing records. This is the first chasm, on the publishing side. They need the assurance that publishing records will, first, do no harm. The beachhead for crossing the publishing-side chasm turned out to be industry leaders. When enough well known domains published records, they seeded the second round of the fax effect. The second round turns potential receiver-side implementors into actual implementors: the early adopters here are the makers of antispam email appliances and edge MTAs such as CipherTrust, IronPort, Postini, and Brightmail. They are ideally positioned to implement Sender ID checking on inbound mail and have a business reason to do so. The second chasm, on the receiving side, requires major ISPs to start implementing inbound checking. Their initial motivation is to reduce the costs of whitelisting. Major ISPs negotiate email peering relationships with major senders and maintain, often by hand, whitelists of IP addresses. Conversion to Sender ID-based whitelisting is an obvious step. Note that while Sender ID is often viewed as an anti-forgery mechanism, using it as a whitelisting mechanism is simply the other side of the coin. After these chasms are crossed, there remains the challenge of getting publishers to transition through increasing levels of severity: from "?" to "~" to "-". This effort requires cooperation from receivers. 7.3. The need for coordinated deployment. The chicken-and-egg problem is this: until forwarders are Sender ID compliant, publishing domains will be reluctant to advance their defaults from "neutral" to "softfail" to "fail". Until publishing domains have a default of "fail", forwarders may see no reason to comply. This problem can be overcome if industry can collectively agree on a deployment schedule that gives all parties enough notice to make the necessary changes. Wong [Page 18] Internet-Draft Sender ID Rationale Jun 23 2004 Normative References [RFC2396] Informative References Other documents in the Sender ID family. Other MARID works in progress. [CSV] [RMX] [DMP] [DVP] [SPF] [DRIP] [MTAMark] [SS] [FSV] [etc] Moore, Geoffrey. Crossing the Chasm. Moore, Geoffrey. Inside the Tornado. de Bono, Edward. Conflict. Alexander, Christopher. A Timeless Way of Building. Fisher & Ury. Getting to Yes. Author Meng Weng Wong Singapore mengwong+spf@pobox.com This document is also available online at http://spf.pobox.com/draft-ietf-marid-rationale-00.txt Comments on this draft are welcome. The appropriate forum for discussion is the MARID Working Group's MXCOMP mailing list at http://www.imc.org/ietf-mxcomp/index.html Wong [Page 19]