|
1 | 1 | # AMP Packager
|
2 | 2 |
|
3 |
| -> **WARNING**: This code is still evolving, and is a developer preview. The |
4 |
| -> specification is still changing, and this is an implementation of a snapshot |
5 |
| -> of it. Feel free to use it, but treat with care how you configure and deploy it. |
6 |
| -
|
7 | 3 | AMP Packager is a tool to [improve AMP
|
8 | 4 | URLs](https://www.ampproject.org/latest/blog/developer-preview-of-better-amp-urls-in-google-search).
|
9 | 5 | By running it in a proper configuration, web publishers may (eventually) have
|
@@ -150,6 +146,21 @@ packager URL directly, first add a Chrome extension to send an
|
150 | 146 | `AMP-Cache-Transform: any` request header. Otherwise, follow the above
|
151 | 147 | "Demonstrate privacy-preserving prefetch" instructions.
|
152 | 148 |
|
| 149 | +##### Security Considerations |
| 150 | +
|
| 151 | +Signed exchanges come with some [security |
| 152 | +considerations](https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#security-considerations) |
| 153 | +that publishers should consider. A starting list of recommendations based on |
| 154 | +that: |
| 155 | +
|
| 156 | + * Use different keys for the signed exchange cert and the TLS cert. |
| 157 | + * Only sign public content that's OK to be shared with crawlers. |
| 158 | + * Don't sign personalized content. (It's OK to sign content that includes |
| 159 | + static JS that adds personalization at runtime.) |
| 160 | + * Be careful when signing inline JS; if it includes a vulnerability, it may be |
| 161 | + possible for attackers to exploit it without intercepting the network path, |
| 162 | + for up to 7 days. |
| 163 | +
|
153 | 164 | #### Testing productionization without a valid certificate
|
154 | 165 |
|
155 | 166 | It is possible to test an otherwise fully production configuration without
|
|
0 commit comments