Web パッケージ用の利用事例と要件

2.1.1. ~offline~installation

~Alexは，~websiteを~containしている~file（ PWA ）を — ~origin %O からの~Service-Workerも含めて — ~downloadして，同僚の~Baileyへ~transmitでき、~Baileyは，それが %O から来た~proofがある下で，~Service-Workerを~installできる。 これは、~Baileyが~websiteを~transferする~bandwidth~costを節約する。 ◎ Alex can download a file containing a website (a PWA) including a Service Worker from origin O, and transmit it to their peer Bailey, and then Bailey can install the Service Worker with a proof that it came from O. This saves Bailey the bandwidth costs of transferring the website.

【 ~Alex, ~Bailey は不特定の誰か（原文では複数人称扱い）。 以下，アルファベット順に~Casey, ~Dakotaも登場する。 】

これを~accomplishする~wayには概ね，次の 2 つがある： ◎ There are roughly two ways to accomplish this:

1. 次に挙げるものだけ~packageする：

   • ~Service-Worker~JS, それが `importScripts()$m する他の~JS
   • 前項の~JSからの `navigator.serviceWorker.register(scriptURL, options)$m ~callを~synthesizeするために~enoughな~URLや~metadata
   • ~interpret済みではないが ~signatureは~check済みの~dataが成す~blobであって、~Service-Workerが自身の~cacheを~fillするために~interpretできるもの。
   ◎ Package just the Service Worker Javascript and any other Javascript that it importScripts(), with their URLs and enough metadata to synthesize a navigator.serviceWorker.register(scriptURL, options) call, along with an uninterpreted but signature-checked blob of data that the Service Worker can interpret to fill in its caches.
2. ~resourceたちを~packageする — ~Service-Workerが それらを `fetch()^m して自身の~cacheを~populateできるような。 ◎ Package the resources so that the Service Worker can fetch() them to populate its cache.

~Service-Workerにだけ~assoc~requirements： ◎ Associated requirements for just the Service Worker:

• `~URLにより~indexされる$ ⇒ `register()^m, `importScripts()^m ~callの~semanticsは、~URLに~dependする。 ◎ Indexed by URL: The register() and importScripts() calls have semantics that depend on the URL.
• `~originとして~signすること$ ⇒ ~fileが %O から来たことを~proveするために。 ◎ Signing as an origin: To prove that the file came from O.
• `~sign時には~existing~TLS~certificateを~useする$ ⇒ これにより、 %O は，~specializeされた~certificate用に大金をはたかずに済む。 ◎ Signing uses existing TLS certificates: So O doesn’t have to spend lots of money buying a specialized certificate.
• `~cryptographic~agility$ ⇒ ~todayの~algoは、~eventualには~obsoleteされ，~replaceする必要が生じることになる。 ◎ Cryptographic agility: Today’s algorithms will eventually be obsolete and will need to be replaced.
• `~certificateの~revocation$ ⇒ %O の~certificateは~compromiseされたり~mis-issueされるかもしれない — ~attackerが~packageを~infiniteに~mintする~abilityを~getするベキでない。 ◎ Certificate revocation: O’s certificate might be compromised or mis-issued, and the attacker shouldn’t then get an infinite ability to mint packages.
• `~downgradeの~prevention$ ⇒ %O の~siteには ~XSS~vulnerabilityがあるかもしれない — ~old~sign済み~packageを持っている~attackerが、~XSSの~advantageを~foreverに得られるベキでない。 ◎ Downgrade prevention: O’s site might have an XSS vulnerability, and attackers with an old signed package shouldn’t be able to take advantage of the XSS forever.
• `~metadata$ ⇒ `register()^m ~callを~generateするに足る，かつ ~W3Cによる~fullな `Application Manifest^cite より少ない。 ◎ Metadata: Just enough to generate the register() call, which is less than a full W3C Application Manifest.

~packageされた~resource用に~assoc~additionalな~requirements： ◎ Additional associated requirements for packaged resources:

• `~URLにより~indexされる$ ⇒ ~web上の~resourceは、~URLにより~addressされる。 ◎ Indexed by URL: Resources on the web are addressed by URL.
• `~request~header$ ⇒ ~Baileyが~Alexとは異なる~browserを~runしていたり，異なる~languageに~configureされている場合、 `Accept*^h ~headerが，各~URLにどの~resourceを~useするか~selectするときに~importantになる。 ◎ Request headers: If Bailey’s running a different browser from Alex or has a different language configured, the accept* headers are important for selecting which resource to use at each URL.
• `~response~header$ ⇒ ~resourceの~HTTP~response~headerは、~resourceの~meaningに深く~influenceする。 ◎ Response headers: The meaning of a resource is heavily influenced by its HTTP response headers.
• `~package内の複数の~originからの~resource$ ⇒ これにより、~siteは ~packageを複数の~libraryから~buildできる 。 ◎ Resources from multiple origins in a package: So the site can be built from multiple components.
• `~metadata$ ⇒ ~browserは、［ ~package~fileの中のどの~resourceを，その~Service-Workerや~initial~HTML~pageとして~treatするか ］~knowする必要がある。 ◎ Metadata: The browser needs to know which resource within a package file to treat as its Service Worker and/or initial HTML page.

2.1.2. ~offlineで~browseするとき

~Alexは、巨大な~website（例： `Wikipedia^ ）を~containしている~fileを，その~originから~downloadして、それを~transfer可能な~storageに~saveして（例： ~SD-card ）から，同僚の~Baileyに~handできる。 ~Baileyは、 %O から来た~proofがある下で，~websiteを~browseできる。 ~Baileyは、~browseする前に，~websiteを~copyするための~storageの空きが足らないこともあろう。 ◎ Alex can download a file containing a large website (e.g. Wikipedia) from its origin, save it to transferrable storage (e.g. an SD card), and hand it to their peer Bailey. Then Bailey can browse the website with a proof that it came from O. Bailey may not have the storage space to copy the website before browsing it.

この~use~caseは、`~offline~installation$を~Service-Worker用に~specializeする場合には，~publisherにとって~supportし難くなる — ~publisherには、~siteを~signできる前に，~Service-Workerを~adoptすることが~requireされるので。 ◎ This use case is harder for publishers to support if we specialize Section 2.1.1 for Service Workers since it requires the publisher to adopt Service Workers before they can sign their site.

`~offline~installation$を超える，~assoc~requirements： ◎ Associated requirements beyond Offline installation:

• `~random~access$ ⇒ ~contentを~useする前に，初めから終わりまで~scanする必要を~avoidする。 ◎ Random access: To avoid needing a long linear scan before using the content.
• `~store済み~packageを~compressする$ ⇒ これにより、同じ~storage~device上に もっと~contentが収まるようになる。 ◎ Compress stored packages: So that more content can fit on the same storage device.

2.1.3. ~web~pageを~saveして~shareする

~Caseyは~web~pageを~viewしていて、~offline~use用に, あるいは友人の~Dakotaにその~pageを~showするために，その~pageを~saveしたいと~wantする。 ~Caseyは~web~pageの~publisherではないので，~pageに~signするために必要な~private鍵は持っていない。 ~current~browserは，~userが~pageを~saveできるようにしているが、~useする~formatは各~browserごとに異なるので（~MHTML ／ ~Web-Archive ／ ~directory内の~file）、~Dakotaと~Caseyは，同じ~browserを~useする必要がある。 ~Caseyは~screenshotも撮れるが、~linkと~accessibilityを~loseする~costと引き換えになる。 ◎ Casey is viewing a web page and wants to save it either for offline use or to show it to their friend Dakota. Since Casey isn’t the web page’s publisher, they don’t have the private key needed to sign the page. Browsers currently allow their users to save pages, but each browser uses a different format (MHTML, Web Archive, or files in a directory), so Dakota and Casey would need to be using the same browser. Casey could also take a screenshot, at the cost of losing links and accessibility.

~assoc~requirements： ◎ Associated requirements:

• `~unsigned~content$ ⇒ ~clientは、~contentを別の~originとして~signし得ない。 ◎ Unsigned content: A client can’t sign content as another origin.
• `~package内の複数の~originからの~resource$ ⇒ ~generalな~web~pageは、複数の~originからの~resourceを~includeする。 ◎ Resources from multiple origins in a package: General web pages include resources from multiple origins.
• `~URLにより~indexされる$ ⇒ ~web上の~resourceは、~URLにより~addressされる。 ◎ Indexed by URL: Resources on the web are addressed by URL.
• `~response~header$ ⇒ ~resourceの~HTTP~response~headerは、~resourceの~meaningに深く~influenceする。 ◎ Response headers: The meaning of a resource is heavily influenced by its HTTP response headers.

2.1.4. ~privacyを~preserveする~prefetch

たくさんの~websiteが、他の~websiteへ~linkする。 これらの~source~siteの多くは、~linkの~targetを~quickに~loadしたがっている。 ~sourceにおいて `<link rel="prefetch">^c を~useすれば，~linkの~targetを~prefetchできるが、そうすると，~userが~linkを~actualに~clickしなくとも，~userが~targetに~linkした~pageを見た~factは~leakされる。 ~TLS~session~IDの様な~mechanismがあるため、これは，~prefetchが~browser~credentialsなしに為された場合にも起こる。 ◎ Lots of websites link to other websites. Many of these source sites would like the targets of these links to load quickly. The source could use <link rel="prefetch"> to prefetch the target of a link, but if the user doesn’t actually click that link, that leaks the fact that the user saw a page that linked to the target. This can be true even if the prefetch is made without browser credentials because of mechanisms like TLS session IDs.

~clientにおける［ ~link~targetを~prefetchする~data用の~budget ］は限られているので、この~use~caseは，~probably［ ~userがどの~linkを~clickする見込みが最も高いか，~accurateに~predictできる~site ］に限られる。 例えば、~search~engineは，~userが最初の数個の~resultいずれかを~clickすることになると~predictでき、 `Reddit^ や `Slashdot^ の様な~news-aggregation~siteは，その討論へ~userが~navigateしたなら，~articleを読むことになると~~期待できる。 ◎ Because clients have limited data budgets to prefetch link targets, this use case is probably limited to sites that can accurately predict which link their users are most likely to click. For example, search engines can predict that their users will click one of the first couple results, and news aggreggation sites like Reddit or Slashdot can hope that users will read the article if they’ve navigated to its discussion.

~todayの~technologyでこれを行う~systemを~buildした~search~engineは，［ `Google^ による AMP ／ `Baidu^ による MIP ］の 2 つがあり，それらの［ ~format, ~cache ］は、~privacyを~preserveしつつ~search~resultを~prefetchすることを~allowする — ~userが~clickした~resultに対し，~wrongな~URLを~showする~costと引き換えに。 この~problemに対する良い~solutionは、~rightな~URLを~showしつつ，依然として~publishしている~origin向けの~requestは ~userが~clickしない限り~avoidするものになるであろう。 ◎ Two search engines have built systems to do this with today’s technology: Google’s AMP and Baidu’s MIP formats and caches allow them to prefetch search results while preserving privacy, at the cost of showing the wrong URLs for the results once the user has clicked. A good solution to this problem would show the right URLs but still avoid a request to the publishing origin until after the user clicks.

~assoc~requirements： ◎ Associated requirements:

• `~originとして~signすること$ ⇒ ~contentが~original~originから来たことを~proveするため。 ◎ Signing as an origin: To prove the content came from the original origin.
• `~stream化された~loading$ ⇒ ~target~pageが~fullに~transferされる前に~userが~clickした場合、~browserは，~source~siteが~page全体の~sendingを~finishする前に，先に得られた各部の~loadingが開始-可能になるベキである。 ◎ Streamed loading: If the user clicks before the target page is fully transferred, the browser should be able to start loading early parts before the source site finishes sending the whole page.
• `~transferを~compressする$ ◎ Compress transfers
• `~subsettingと~reordering$ ⇒ ~prefetchした~pageが，ある~imageを成す~subresourceを~includeする場合、~subresourceの~publisherは，~imageの［ ~WebP, ~PNG ］両~versionとも~provideして~signしたいと~wantするかもしれないが、~source~siteは，各~clientに対し~bestな 1 つのみ~transfer可能になるベキである。 ◎ Subsetting and reordering: If a prefetched page includes subresources, its publisher might want to provide and sign both WebP and PNG versions of an image, but the source site should be able to transfer only best one for each client.

2.2.1. ~packageされた~web~publication

`IDPF^（ `International Digital Publishing Forum^en ）と合併した ~W3Cの Publishing Working Group は、 `EPUB^ の~maintenanceを任される中で，［ 異なる~serverや他の~userへ，~arbitraryな~protocolを介して~copyできるような~publication ］を~web上に~create可能にしたいと~wantしている。 ~detailsは Packaged Web Publications use cases （ ~packageされた~web~publicationの~use~case ）を見よ。 ◎ The W3C’s Publishing Working Group, merged from the International Digital Publishing Forum (IDPF) and in charge of EPUB maintenance, wants to be able to create publications on the web and then let them be copied to different servers or to other users via arbitrary protocols. See their Packaged Web Publications use cases for more details.

~assoc~requirements： ◎ Associated requirements:

• `~URLにより~indexされる$ ⇒ ~web上の~resourceは、~URLにより~addressされる。 ◎ Indexed by URL: Resources on the web are addressed by URL.
• `~originとして~signすること$ ⇒ これにより、読者は，手元の~copyが~authenticであることを~~確認でき、~packageを~copyしても~insideにある~contentの~URLは~preserveされる。 ◎ Signing as an origin: So that readers can be sure their copy is authentic and so that copying the package preserves the URLs of the content inside it.
• `~downgradeの~prevention$ ⇒ ~publicationの早期~versionは、~incorrectな~contentを~containするかもしれない。 ~publisherは — ~attackerが，~old~contentを依然として~userに~showできることに~worryすることなく — ~update可能になるベキである。 ◎ Downgrade prevention: An early version of a publication might contain incorrect content, and a publisher should be able to update that without worrying that an attacker can still show the old content to users.
• `~metadata$ ⇒ ~publicationの関心事には、~copyrightや~licensingも含まれ得る。 ［ ~title, 著作者, 表紙~image, ~ISBNや~DOI名, 等々 ］は、その~publicationが~packageされるときに，~includeされるベキである。 ◎ Metadata: A publication can have copyright and licensing concerns; a title, author, and cover image; an ISBN or DOI name; etc.; which should be included when that publication is packaged.

他の~requirementsは、`~offline~installation$と~similarになる： ◎ Other requirements are similar to those from Offline installation:

• `~random~access$ ⇒ ~contentを~useする前に，初めから終わりまで~scanする必要を~avoidする。 ◎ Random access: To avoid needing a long linear scan before using the content.
• `~store済み~packageを~compressする$ ⇒ これにより、同じ~storage~device内にもっと~contentが収まるようになる。 ◎ Compress stored packages: So that more content can fit on the same storage device.
• `~request~header$ ⇒ 各~browserの~capabilitiesや~preferenceが，~userごとに異なる場合、各~URLにどの~resourceを~useするか~selectするときに， `Accept*^h ~headerが~importantになる。 ◎ Request headers: If different users’ browsers have different capabilities or preferences, the accept* headers are important for selecting which resource to use at each URL.
• `~response~header$ ⇒ ~resourceの~HTTP~response~headerは、~resourceの~meaningに深く~influenceする。 ◎ Response headers: The meaning of a resource is heavily influenced by its HTTP response headers.
• `~sign時には~existing~TLS~certificateを~useする$ ⇒ これにより、~publisherは，~specializeされた~certificate用に大金をはたかずに済む。 ◎ Signing uses existing TLS certificates: So a publisher doesn’t have to spend lots of money buying a specialized certificate.
• `~cryptographic~agility$ ⇒ ~todayの~algoは、~eventualには~obsoleteされ，~replaceする必要が生じることになる。 ◎ Cryptographic agility: Today’s algorithms will eventually be obsolete and will need to be replaced.
• `~certificateの~revocation$ ⇒ ~publisherの~certificateは~compromiseされたり~mis-issueされるかもしれない — ~attackerが~infiniteに~packageを~mintする~abilityを~getするベキでない。 ◎ Certificate revocation: The publisher’s certificate might be compromised or mis-issued, and an attacker shouldn’t then get an infinite ability to mint packages.

2.2.2. ~censorshipの~avoiding

一部の~userは、［ ~governmentや~network~providerが彼らに見せたくないと~wantする~resource ］を，~retrieveしたいと~wantする。 ~privilegedな~network~positionにある誰かにとって，~particular~hostへの~accessを~blockするのは 今すぐにでも~straightforwardだが、そのような~host上の~particular~resourceだけ~accessを~blockするのは，~TLSの下では~difficultである。 ◎ Some users want to retrieve resources that their governments or network providers don’t want them to see. Right now, it’s straightforward for someone in a privileged network position to block access to particular hosts, but TLS makes it difficult to block access to particular resources on those hosts.

~todayにおいて，［ ~blockされた~contentを，~third-partyから~retrieveする ］のは~straightforwardだが、［ ~third-partyが当の~contentの~accurateな~representationを~userへ~sendしたかどうか ］の~guaranteeは無い — ~userは、~third-partyを~trustする必要がある。 ◎ Today it’s straightforward to retrieve blocked content from a third party, but there’s no guarantee that the third-party has sent the user an accurate representation of the content: the user has to trust the third party.

~sign済み~web~packageがあれば、~userは，~censorshipは依然として~bypassしつつ, ~contentは~authenticである~assuranceを取り戻せる。 ~packageには、この~contentの【~censorshipによる】~discoverを~helpするものは何らない。 ◎ With signed web packages, the user can re-gain assurance that the content is authentic, while still bypassing the censorship. Packages don’t do anything to help discover this content.

~censorshipを~difficultにする~systemは、~legitimateな~content~filteringも~difficultにする。 ~web~packageを~processする~clientは，常に真の~URLを~knowするので、このことは，~content~filteringは — ~network上に代えて — ~client上で~happenすることを強いる。 ◎ Systems that make censorship more difficult can also make legitimate content filtering more difficult. Because the client that processes a web package always knows the true URL, this forces content filtering to happen on the client instead of on the network.

~assoc~requirements： ◎ Associated requirements:

• `~URLにより~indexされる$ ⇒ これにより、~userは，自身が~expectする~contentを~getしていることを見れる。 ◎ Indexed by URL: So the user can see that they’re getting the content they expected.
• `~originとして~signすること$ ⇒ これにより、読者は，手元の~copyが~authenticであることを~~確認でき、~packageを~copyしても~insideにある~contentの~URLは~preserveされる。 ◎ Signing as an origin: So that readers can be sure their copy is authentic and so that copying the package preserves the URLs of the content inside it.

2.2.3. ~third-partyによる~security~review

一部の~userは、~securityついて，~trust済みの~third-partyにより~reviewされた~appに限り，一定の~permissionを~grantしたいと~wantすることもあろう。 これらの~third-partyは、［ `iOS^ ／ `Android^ ／ `Chrome OS^ ~app~store0 ］が~provideするものに~similarな~guaranteeを~provideすることもでき、［ ~audit済みでないが~safeと~deemされた~website用に，より~powerfulな~capabilitiesを~offerする ］ことを，~browserに~allowするかもしれない。 ◎ Some users may want to grant certain permissions only to applications that have been reviewed for security by a trusted third party. These third parties could provide guarantees similar to those provided by the iOS, Android, or Chrome OS app stores, which might allow browsers to offer more powerful capabilities than have been deemed safe for unaudited websites.

~website用の~binary~transparencyも~similarになる： Certificate Transparency 【証明書の透明性】 `RFC6962$r と同様に，~transparency~logは、~packageの~contentを~signして，［ ~clientが~receiveした~exactな~packageを，~expertたちが~auditする~chanceがあった ］ことの~assuranceを~provideすることになろう。 ◎ Binary transparency for websites is similar: like with Certificate Transparency [RFC6962], the transparency logs would sign the content of the package to provide assurance that experts had a chance to audit the exact package a client received.

~assoc~requirements： ◎ Associated requirements:

• `~additionalな~signature$ ◎ Additional signatures

2.2.4. ~packageを複数の~libraryから~buildするとき

巨大な~programは、より小さな~componentから~buildされる。 ~webの場合、各~componentは［ ~JS~fileか, `iframe^e 化された~subresource ］として~includeされ得る。 前者の~caseでは，~packagerは，~JS~fileを~own~originに~copyすることもできるが、後者の~caseでは， `iframe^e 化された~resourceにとって［ `~same-origin$向けの~requestを，~own~origin向けに発行し直せる ］ことが~importantになり得る — 例えば， `federated sign-in^en 【！＊】を~implementするため。 ◎ Large programs are built from smaller components. In the case of the web, components can be included either as Javascript files or as <iframe>d subresources. In the first case, the packager could copy the JS files to their own origin; but in the second, it may be important for the <iframe>d resources to be able to make same-origin requests back to their own origin, for example to implement federated sign-in.

~assoc~requirements： ◎ Associated requirements:

• `~package内の複数の~originからの~resource$ ⇒ 各~componentは、その~own~originから来ることもある。 ◎ Resources from multiple origins in a package: Each component may come from its own origin.
• `~diamond~dependencyの~deduplication$ ⇒ 2 つの~dependency A→B→D, A→C→D がある場合、~resource D への~requestは~single~resourceに~resolveされつつ， B, C とも それを~handleできることが~importantになる。 ◎ Deduplication of diamond dependencies: If we have dependencies A->B->D and A->C->D, it’s important that a request for a D resource resolves to a single resource that both B and C can handle.

2.2.5. ~CDNをまたがる~serve法

~web~pageが，異なる~originからの~subresourceを有するとき、それらの~subresourceの~retrievalは、~main~resourceと同じ~connection越しに~transferされれば~optimizeできる。 両~originとも同じ~CDNから~distributeされる場合、 `I-D.ietf-httpbis-http2-secondary-certs$r の様な~progress中の~mechanismが，両~resourceとも~sendする~single~connectionを~useすることを~serverに~allowするが、当の~resourceと~subresourceが ~CDNを~shareしない／全く~useしない場合、~existing~mechanismは~helpにならない。 ◎ When a web page has subresources from a different origin, retrieval of those subresources can be optimized if they’re transferred over the same connection as the main resource. If both origins are distributed by the same CDN, in-progress mechanisms like [I-D.ietf-httpbis-http2-secondary-certs] allow the server to use a single connection to send both resources, but if the resource and subresource don’t share a CDN or don’t use a CDN at all, existing mechanisms don’t help.

当の~subresourceが~publisherにより~signされた場合には、~main~resourceの~serverは それを~clientへ~forwardできる。 ◎ If the subresource is signed by its publisher, the main resource’s server can forward it to the client.

~client, ~serverが~clientの~cache内にすでにある~subresourceを~transferするのを~avoidしたいと~wantする場合、まだ~solveされてない~privacy~problemがある — ~naiveに，~resourceはすでに在ると~serverに~tellするのでは、~privacy~leakになる。 ◎ There are some yet-to-be-solved privacy problems if the client and server want to avoid transferring subresources that are already in the client’s cache: naively telling the server that a resource is already present is a privacy leak.

~assoc~requirements： ◎ Associated requirements:

• `~stream化された~loading$ ⇒ ~optimalな~performanceを得るため、~browserは — ~distributorが~resource全体の~sendingを~finishする前に — ~resourceを成す先に得られた各部の~loadingを開始-可能になるベキである。 ◎ Streamed loading: To get optimal performance, the browser should be able to start loading early parts of a resource before the distributor finishes sending the whole resource.
• `~originとして~signすること$ ⇒ ~contentが~original~originから来たことを~proveするため。 ◎ Signing as an origin: To prove the content came from the original origin.
• `~transferを~compressする$ ◎ Compress transfers

2.2.6. ~self-extracting~executableからの~installation

`Node^ や `Electron^ の~communityは、~self-extracting~executableを~useして~packageを~installしたいであろう。 ~self-extracting~executableを~designする~traditionalな~wayは、 ~executableの末尾に~packageを~concatenateするものである — ~executableは、~packageの~endから~packageの~lengthを探し出し，そこから~packageの~startへ~backwardsへ~seekする。 ◎ The Node and Electron communities would like to install packages using self-extracting executables. The traditional way to design a self-extracting executable is to concatenate the package to the end of the executable, have the executable look for a length at its own end, and seek backwards from there for the start of the package.

~assoc~requirements： ◎ Associated requirements:

• `~trailing~length$ ◎ Trailing length

2.2.7. ~version~controlにおける~package

~generateされた各~packageは、~version~controlの下で~storeされるベキである。 ~popularな多くの~version~control~systemは、~text~fileを~auto-~detectして，その~line-endingを “~fixする” 。 ~packageの最初の~byte列は~textの様に見えつつ，後続の~byte列は~binary~dataを~storeしている場合、~version~controlは~packageを壊すことになろう。 ◎ Once packages are generated, they should be stored in version control. Many popular VC systems auto-detect text files in order to “fix” their line endings. If the first bytes of a package look like text, while later bytes store binary data, VC may break the package.

~assoc~requirements： ◎ Associated requirements:

• `~binary$ ◎ Binary

2.2.8. ~subresourceの~bundle法

~textに基づく一連の~subresourceを一緒に~bundleすれば、~compression~ratioが~improveされる~benefitが得られることが多い。 ◎ Text based subresources often benefit from improved compression ratios when bundled together.

と同時に，~JSや~CSSを~bundleする~current~practiceにおいては、~single~JS~fileの中に何もかもを~compileすることによる，~negativeな~side-effectもある： ◎ At the same time, the current practice of JS and CSS bundling, by compiling everything into a single JS file, also has negative side-effects:

1. ~dependent~execution ⇒ ~bundleされた~resourceたちのうち`どれであろうが^em，それを~executeし始めるためには、`それらすべて^emを［ ~downloadして, ~parseして, ~executeする ］ことが~requireされる。 ◎ Dependent execution - in order to start executing any of the bundled resources, it is required to download, parse and execute all of them.
2. ~cachingの~granularityが~lostする ⇒ 各~resourceの`どれか^emが~modificationされると， `それらすべて^emの~cachingが無効化される~resultになる。 ◎ Loss of caching granularity - Modification of any of the resources results in caching invalidation of all of them.
3. ~module~semanticsが~lostする ⇒ ES6 の各~moduleは、互いに~independentな~resourceとして~deliverされなければならない。 しかしながら，~current~bundling~methodは、~commonな~URLの下でそれらを他の~resourceと伴に~deliverするので， `ES5^ へ~transpileすることが~requireされる。 その~resultとして、 `ES6^ ~module~semanticsが~lostする。 ◎ Loss of module semantics - ES6 modules must be delivered as independent resources. Therefore, current bundling methods, which deliver them with other resources under a common URL, require transpilation to ES5 and result in loss of ES6 module semantics.

各~resourceが［ ~own~URLを~maintainしつつ，他の~resourceとともに~physicalに~deliverされる ］ことを~enableするような，~on-the-flyに~readableな~package用の~formatは、~compression~ratioを~improveする~upsideを~keepしつつ，上の~downsideを~resolveできる。 ◎ An on-the-fly readable packaging format, that will enable resources to maintain their own URLs while being physically delivered with other resources, can resolve the above downsides while keeping the upsides of improved compression ratios.

~cacheの~granularityを~improveするためには、~clientは，どの~resourceのどの~versionがすでに~cacheされたか~serverに~tellする必要がある — それは、~Service-Workerで，あるいは~perhaps `I-D.ietf-httpbis-cache-digest$r でも行える。 ◎ To improve cache granularity, the client needs to tell the server which versions of which resources are already cached, which it could do with a Service Worker or perhaps with [I-D.ietf-httpbis-cache-digest].

~assoc~requirements： ◎ Associated requirements:

• `~URLにより~indexされる$ ◎ Indexed by URL
• `~stream化された~loading$ ⇒ ~downsideのうち，~dependent~executionを~solveするため。 ◎ Streamed loading: To solve downside 1.
• `~transferを~compressする$ ⇒ ~upsideを~keepするため。 ◎ Compress transfers: To keep the upside.
• `~response~header$ ⇒ ~JSと~CSSを~loadするためには少なくとも `Content-Type$h が必要になる。 ◎ Response headers: At least the Content-Type is needed to load JS and CSS.
• `~unsigned~content$ ⇒ ~same-origin~contentを~signしても，空きを~wasteするだけである。 ◎ Unsigned content: Signing same-origin content wastes space.

2.2.9. ~archival

~WARC `ISO28500$r の様な~existing~formatは、~particular時点における~web~serverの~stateを~accurateに~representする良い~jobを行うが、~currently~browserは，その~websiteが~archiveされた時点の~experienceを~personに与えるものとしては、それらを~useできない。 この~draftの策定者にとっては、~package用の~new~formatが — 例えば、~browserにおいて，~WARC用の~supportを~implementすることに~compareして — ~WARCを~improveすると見込まれるかどうかは~obviousでないが、~archive法について~knowする者たちからは関心があると見受けられる — 例： https://twitter.com/anjacks0n/status/950861384266416134 ◎ Existing formats like WARC ([ISO28500]) do a good job of accurately representing the state of a web server at a particular time, but a browser can’t currently use them to give a person the experience of that website at the time it was archived. It’s not obvious to the author of this draft that a new packaging format is likely to improve on WARC, compared to, for example, implementing support for WARC in browsers, but folks who know about archiving seem interested, e.g.: https://twitter.com/anjacks0n/status/950861384266416134.

~archivalには~time-scaleが~involveされるため、~original~hostからのどの~signatureも，~archiveを~viewする時点では それ以上~trustできない見込みが高い。 なので，~implementationは、~original~origin上で~runする代わりに，~contentを~sandbox化する必要がある。 ◎ Because of the time scales involved in archival, any signatures from the original host would likely not be trusted anymore by the time the archive is viewed, so implementations would need to sandbox the content instead of running it on the original origin.

~assoc~requirements： ◎ Associated requirements:

• `~URLにより~indexされる$ ◎ Indexed by URL
• `~response~header$ ⇒ ~serverの~responseを~accurateに~recordするため。 ◎ Response headers: To accurately record the server’s response.
• `~unsigned~content$ ⇒ ~expireした~signatureに~~対処するため。 ◎ Unsigned content: To deal with expired signatures.
• `~time-shifting~execution$ ◎ Time-shifting execution

3.1.1. ~URLにより~indexされる

~resourceは、~URLを~keyとするベキである — ~browserが~HTTP越しに~resourceを~look-upする方法に~matchするよう。 ◎ Resources should be keyed by URLs, matching how browsers look resources up over HTTP.

3.1.2. ~request~header

~resource~keyは、~content~negotiateされた~resourceを~representできるよう， `Accept$h や `Accept-Language$h の様な~request~headerを~includeするベキである。 ◎ Resource keys should include request headers like accept and accept-language, which allows content-negotiated resources to be represented.

これは、 `MHTML$r に対する~extensionを~requireすることになろう — それは， `Content-Location$h ~response~headerを~useして~requestされた~URLを~encodeするが、他の~request~headerを~encodeする~wayは無いので。 ~MHTMLには、同じ `Content-Location$h を伴う複数の~resourceを~handleするための~instructionも無い。 ◎ This would require an extension to [MHTML], which uses the content-location response header to encode the requested URL, but has no way to encode other request headers. MHTML also has no instructions for handling multiple resources with the same content-location.

これは `ZIP$r に対する~extensionも~requireする — 各~request~headerを~ZIPの~filename~fieldの中に~encodeする必要がある。 ◎ This also requires an extension to [ZIP]: we’d need to encode the request headers into ZIP’s filename fields.

3.1.3. ~response~header

~resourceは、次に挙げる様な~HTTP~response~headerを~includeするベキである ⇒＃ `Content-Type$h, `Content-Encoding$h, `Expires$h, `Content-Security-Policy$h, 等々。 ◎ Resources should include their HTTP response headers, like content-type, content-encoding, expires, content-security-policy, etc.

これは `ZIP$r に対する~extensionを~requireする ⇒ `JAR$r の `META-INF^c ~directoryの様な何かで ~resourceの~bodyを超える~extra~metadataを~holdする必要があろう。 ◎ This requires an extension to [ZIP]: we’d need something like [JAR]’s META-INF directory to hold extra metadata beyond the resource’s body.

3.1.4. ~originとして~signすること

~packageの中の各~resourceは、［ ~resourceの~origin `RFC6454$r 向けの~HTTPS~requestを~serveする~abilityを備える~entity ］から得られたものと，~proveされること。 ◎ Resources within a package are provably from an entity with the ability to serve HTTPS requests for those resources’ origin [RFC6454]. ◎ 重複 Resources within a package are provably from an entity with the ability to serve HTTPS requests for those resources’ origin [RFC6454].

~HTTP~messageを~signするための以前の~attempt（ `I-D.thomson-http-content-signature$r, `I-D.burke-content-signature$r, `I-D.cavage-http-signatures$r ）は、［ ~resourceが~particular~originから来たことを~proveするために、~clientが~signatureをどう~useするベキか ］についての~descriptionを~omitするので，この~purposeには ~probably~use可能でないことに注意。 ◎ Note that previous attempts to sign HTTP messages ([I-D.thomson-http-content-signature], [I-D.burke-content-signature], and [I-D.cavage-http-signatures]) omit a description of how a client should use a signature to prove that a resource comes from a particular origin, and they’re probably not usable for that purpose.

これには、 `ZIP$r ~formatに対し， `JAR$r の~signatureに~similarな~extensionが~requireされることになる。 ◎ This would require an extension to the [ZIP] format, similar to [JAR]’s signatures.

どの~cryptographic~systemにおいても、~specは，~incorrectな~implementationよりも ~correctな~implementationを~deployし易くする責務がある（`~wrongな~implementationになり難くする$）。 ◎ In any cryptographic system, the specification is responsible to make correct implementations easier to deploy than incorrect implementations (Section 3.1.12).

3.1.5. ~random~access

~disk上に~storeされた~packageに対しては、~browserは，初めから終わりまで~scanせずに~arbitraryな~resourceに~accessできること。 ◎ When a package is stored on disk, the browser can access arbitrary resources without a linear scan.

`MHTML$r は、［ ~containする各~resourceの~byte~offsetからなる~index ］も伴うように~extendされる必要がある。 ◎ [MHTML] would need to be extended with an index of the byte offsets of each contained resource.

3.1.6. ~package内の複数の~originからの~resource

~origin %O からの~packageは、別の~originからの — %O と同じ~levelで~authenticateされた — ~resourceを~containできること。 ◎ A package from origin A can contain resources from origin B authenticated at the same level as those from A.

3.1.7. ~cryptographic~agility

~obsoleteな~cryptographic~algoは、~replaceできること。 ◎ Obsolete cryptographic algorithms can be replaced.

~cryptographyの~upgradeを~planすることは、~old~cryptographyをいつ~removeすれば~safeなのかを~knowするための，何らかの~wayを含めるベキであることも~meanする（§`~old~cryptoを~removeできる$）。 ◎ Planning to upgrade the cryptography also means we should include some way to know when it’s safe to remove old cryptography (Section 3.2.5).

3.1.8. ~unsigned~content

~Alexは，~CAにより~signされた~certificateを伴う~own~packageを~createでき、~Baileyは，その~packageの~contentを~viewできること。 ◎ Alex can create their own package without a CA-signed certificate, and Bailey can view the content of the package.

3.1.9. ~certificateの~revocation

ある~packageを~signしている~certificateが~revokeされたなら、~online~browserはこれを~reasonableに~quickに~detectできること。 ◎ When a package is signed by a revoked certificate, online browsers can detect this reasonably quickly.

3.1.10. ~downgradeの~prevention

~browserが［ ~vulnerableな~versionの~packageの，より~new~version ］を見て以降は、~attackerが~oldな方を~browserに~trustさせ得なくすること。 ◎ Attackers can’t cause a browser to trust an older, vulnerable version of a package after the browser has seen a newer version.

3.1.11. ~metadata

~W3Cによる `Application Manifest^cite `W3C.WD-appmanifest-20170828$r に~findされる様な~metadataがあること — ~packageを~loadして~displayする方法を，~clientが~knowするのを~helpするために。 ◎ Metadata like that found in the W3C’s Application Manifest [W3C.WD-appmanifest-20170828] can help a client know how to load and display a package.

3.1.12. ~wrongな~implementationになり難くする

~designは、［ ~incorrectな~implementationには、~quickに~noticeされる~tendがある~aspect ］を~incorporateして，［ ~incorrectに~implementし易くなる~aspect ］を~avoidするベキである。 例えば： ◎ The design should incorporate aspects that tend to cause incorrect implementations to get noticed quickly, and avoid aspects that are easy to implement incorrectly. For example:

• ~cryptographic~algo~identifier `RFC7515$r を~explicitに~specifyすると、 ~implementationがその~algoを~easyに~trustしてしまい， ~vulnerabilityをもたらす 。 ◎ Explicitly specifying a cryptographic algorithm identifier in [RFC7515] made it easy for implementations to trust that algorithm, which caused vulnerabilities.
• `ZIP$r における~filenameの~duplicate~specificationは、~implementationが 片方だけ~signatureを~checkしながら他方を~use し易くしてしまう。 ◎ [ZIP]’s duplicate specification of filenames makes it easy for implementations to check the signature of one copy but use the other.

• ~possibleなときは， Langley の法則† に~followすることにより、~incorrectな~implementationは~deployし難くなる。 ◎ Following Langley’s Law when possible makes it hard to deploy incorrect implementations.

  【† 要約： “~sendするものは ときどき~evilに，~acceptするものは~conservativeに” — Postel の法則（ “~sendするものは~conservativeに，~acceptするものは~liberalに” ）の反対。 】

3.2.1. ~stream化された~loading

~browserが、~packageを~downloadしながら~loadできること。 ◎ The browser can load a package as it downloads.

これは~ZIPと~conflictする — ~ZIPの~indexは末尾にあるので。 ◎ This conflicts with ZIP, since ZIP’s index is at the end.

3.2.2. ~additionalな~signature

~third-partyが、~packageを~signすることにより，~packageを~vouchできること。 ◎ Third-parties can vouch for packages by signing them.

3.2.3. ~binary

~binary~formatは、［ ~line-endingを “~fixしようと” ~tryするかもしれない~tool ］により，~binaryとして~identifyされること。 ◎ The format is identified as binary by tools that might try to “fix” line endings.

これは、 `MHTML$r 基づく~formatの~use法と~conflictする。 ◎ This conflicts with using an [MHTML]-based format.

3.2.4. ~diamond~dependencyの~deduplication

同じ~sub-packageへの複数の~dependency~routeがある ~nested~packageは、各~sub-packageにつき 1 個だけ~copyを~transmitして~storeできること。 ◎ Nested packages that have multiple dependency routes to the same sub-package, can be transmitted and stored with only one copy of that sub-package.

3.2.5. ~old~cryptoを~removeできる

~ecosystemは、~obsoleteな~cryptographic~algoがもはや必要なくなったときを~identifyでき，~removeできること。 ◎ The ecosystem can identify when an obsolete cryptographic algorithm is no longer needed and can be removed.

3.2.6. ~transferを~compressする

~network越しに~transferされる~packageが占める~byte数は、~possibleな限り少なく抑えること。 これは、`~random~access$を~preserveする必要はないので，`~store済み~packageを~compressする$より~easyな~problemである。 ◎ Transferring a package over the network takes as few bytes as possible. This is an easier problem than Compress stored packages since it doesn’t have to preserve Random access.

3.2.7. ~store済み~packageを~compressする

~packageを~diskに~storeするときに占める~byte数は、~possibleな限り少なく抑えること。 ◎ Storing a package on disk takes as few bytes as possible.

3.2.8. ~subsettingと~reordering

~packageの中の~resourceたちを， `~originとして~signすること$に反することなく［ ~removeできる／~reorderできる ］こと。 ◎ Resources can be removed from and reordered within a package, without breaking signatures.

3.2.9. ~packageされた~validity~information

［ `~certificateの~revocation$ ／ `~downgradeの~prevention$ ］~information自体を、~packageできる, あるいは他の~package内に~includeできること。 ◎ Certificate revocation and Downgrade prevention information can itself be packaged or included in other packages.

3.2.10. ~sign時には~existing~TLS~certificateを~useする

“~normalな” ~TLS~certificateを，~packageを~signするために~useできること。 “~code~signing” ~certificateの様な~extra~requirementsを~avoidすれば、~packagingは，すべての~siteから より~access可能になる。 ◎ A “normal” TLS certificate can be used for signing packages. Avoiding extra requirements like “code signing” certificates makes packaging more accessible to all sites.

3.2.11. ~external~dependency

各~sub-packageは、~main~packageから “~external化” できること — すなわち，~browserは、それらを別々に~fetchするか，すでに持っている必要がある。 （ #35, App Installer Story ） ◎ Sub-packages can be “external” to the main package, meaning the browser will need to either fetch them separately or already have them. (#35, App Installer Story)

3.2.12. ~trailing~length

~byte単位による~packageの~lengthは、~packageの末尾から~fixedな~offsetの所に~appearすること。 ◎ The package’s length in bytes appears a fixed offset from the end of the package.

これは、 `MHTML$r と~conflictする。 ◎ This conflicts with [MHTML].

3.2.13. ~time-shifting~execution

一部の~unsigned~packageにおいては、~JSの~timeを得る関数【 `Date.now()^m 等】は — 真の~current~timeではなく — ~packageの~timestampを~returnするベキである。 ◎ In some unsigned packages, Javascript time-telling functions should return the timestamp of the package, rather than the true current time.

これに~security上の~implicationsがあるかどうか、~exploreするベキである。 ◎ We should explore if this has security implications.