forked from mozilla/standards-positions
-
Notifications
You must be signed in to change notification settings - Fork 0
/
activities.json
1085 lines (1085 loc) · 72.3 KB
/
activities.json
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
[
{
"ciuName": null,
"description": "Adds imagesrcset and imagesizes attributes to <link> which correspond to the srcset and sizes attributes of <img> respectively, for the purposes of preloading.",
"id": "image-preload",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1515760",
"mozPosition": "worth prototyping",
"mozPositionDetail": "A relevant aspect of <link rel=preload> support.",
"mozPositionIssue": 130,
"org": "WHATWG",
"title": "<link>'s imagesrcset and imagesizes attributes",
"url": "https://html.spec.whatwg.org/multipage/semantics.html#attr-link-imagesrcset"
},
{
"ciuName": null,
"description": "",
"id": "aria-annotations",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1608975",
"mozPosition": "important",
"mozPositionDetail": "This contains changes needed to support screen reader accessibility of comments, suggestions, and other annotations in published documents and online word processing applications.",
"mozPositionIssue": 253,
"org": "W3C",
"title": "ARIA Annotations",
"url": "https://github.com/aleventhal/aria-annotations"
},
{
"ciuName": null,
"description": "This document describes an API providing access to accelerated shape detectors (e.g. human faces) for still images and/or live image feeds.",
"id": "shape-detection-api",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1553738",
"mozPosition": "defer",
"mozPositionDetail": "We're concerned about possible complexity, variations in support between operating systems, and possible fingerprinting surface, but we'd like to wait and see how this proposal evolves.",
"mozPositionIssue": 21,
"org": "Proposal",
"title": "Accelerated Shape Detection in Images",
"url": "https://wicg.github.io/shape-detection-api"
},
{
"ciuName": null,
"description": "This memo introduces an informational HTTP status code that can be used to convey hints that help a client make preparations for processing the final response.",
"id": "http-early-hints",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1407355",
"mozPosition": "worth prototyping",
"mozPositionDetail": "We believe that experimentation with the 103 response code is worthwhile, while at the same time noting that its primary benefit comes from using it with rel=preload, which Firefox does not yet implement. We do have some concerns about the lack of clear interaction with Fetch, which we hope will be specified before the mechanism is put into widespread use.",
"mozPositionIssue": 134,
"org": "IETF",
"title": "An HTTP Status Code for Indicating Hints (103)",
"url": "https://tools.ietf.org/html/rfc8297"
},
{
"ciuName": null,
"description": "This specification defines an API allowing web applications to set an application-wide badge, shown in an operating-system-specific place associated with the application (such as the shelf or home screen), for the purpose of notifying the user when the state of the application has changed (e.g., when new messages have arrived), without showing a more heavyweight notification.",
"id": "badging",
"mozBugUrl": null,
"mozPosition": "worth prototyping",
"mozPositionDetail": null,
"mozPositionIssue": 108,
"org": "Proposal",
"title": "Badging API",
"url": "https://wicg.github.io/badging/"
},
{
"ciuName": null,
"description": "This proposal adds arbitrary-precision integers to ECMAScript.",
"id": "bigint",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1366287",
"mozPosition": "non-harmful",
"mozPositionDetail": "Shipping in Firefox.",
"mozPositionIssue": 65,
"org": "Ecma",
"title": "BigInt",
"url": "https://tc39.github.io/proposal-bigint/"
},
{
"ciuName": null,
"description": "Bundled exchanges provide a way to bundle up groups of HTTP request+response pairs to transmit or store them together. They can include multiple top-level resources with one identified as the default by a manifest, provide random access to their component exchanges, and efficiently store 8-bit resources.",
"id": "bundled-exchanges",
"mozBugUrl": null,
"mozPosition": "under consideration",
"mozPositionDetail": null,
"mozPositionIssue": 264,
"org": "Proposal",
"title": "Bundled HTTP Exchanges",
"url": "https://tools.ietf.org/html/draft-yasskin-wpack-bundled-exchanges"
},
{
"ciuName": null,
"description": "This draft defines additions to CSS Grid, primarily for the subgrid feature.",
"id": "subgrid",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1349043",
"mozPosition": "important",
"mozPositionDetail": "Subgrid adds a critical enhancement to CSS Grid, in particular for many CSS Grid use-cases that require alignment across nested semantic elements.",
"mozPositionIssue": 125,
"org": "W3C",
"title": "CSS Grid Layout Module Level 2",
"url": "https://drafts.csswg.org/css-grid-2/"
},
{
"ciuName": null,
"description": "An API for allowing web developers to define their own layout modes with javascript.",
"id": "css-layout-api",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1302337",
"mozPosition": "worth prototyping",
"mozPositionDetail": "This specification allows developing prototypes of new CSS layout systems and provides an escape hatch for developers when the existing systems aren't good enough for a particular piece of a web page.",
"mozPositionIssue": 93,
"org": "W3C",
"title": "CSS Layout API",
"url": "https://drafts.css-houdini.org/css-layout-api-1"
},
{
"ciuName": "css-paint-api",
"description": "An API for allowing web developers to define a custom CSS <image> with javascript, which will respond to style and size changes.",
"id": "css-paint-api",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1302328",
"mozPosition": "worth prototyping",
"mozPositionDetail": "This specification allows developing prototypes of new graphical CSS features and provides an escape hatch for developers when the existing features aren't good enough for a particular piece of a web page.",
"mozPositionIssue": 93,
"org": "W3C",
"title": "CSS Painting API",
"url": "https://drafts.css-houdini.org/css-paint-api-1"
},
{
"ciuName": null,
"description": "This CSS module defines an API for registering new CSS properties. Properties registered using this API are provided with a parse syntax that defines a type, inheritance behaviour, and an initial value.",
"id": "css-properties-and-values-api",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1273706",
"mozPosition": "worth prototyping",
"mozPositionDetail": "This specification makes it significantly easier to use CSS custom properties in ways that are more like regular CSS properties.",
"mozPositionIssue": 93,
"org": "W3C",
"title": "CSS Properties and Values API",
"url": "https://drafts.css-houdini.org/css-properties-values-api-1"
},
{
"ciuName": null,
"description": "The @property rule represents a custom property registration directly in a stylesheet without having to run any JS.",
"id": "at-property",
"mozBugUrl": null,
"mozPosition": "worth prototyping",
"mozPositionDetail": "Having a declarative registration mechanism for custom properties is a good addition to CSS Properties and Values API.",
"mozPositionIssue": 331,
"org": "W3C",
"title": "CSS Properties and Values API: @property",
"url": "https://drafts.css-houdini.org/css-properties-values-api-1#at-property-rule"
},
{
"ciuName": null,
"description": "This specification defines the ::part() and ::theme() pseudo-elements on shadow hosts, allowing shadow hosts to selectively expose chosen elements from their shadow tree to the outside page for styling purposes.",
"id": "css-shadow-parts",
"mozBugUrl": null,
"mozPosition": "worth prototyping",
"mozPositionDetail": null,
"mozPositionIssue": 59,
"org": "W3C",
"title": "CSS Shadow Parts",
"url": "https://drafts.csswg.org/css-shadow-parts"
},
{
"ciuName": null,
"description": "Converting CSSOM value strings into meaningfully typed JavaScript representations and back can incur a significant performance overhead. This specification exposes CSS values as typed JavaScript objects to facilitate their performant manipulation.",
"id": "css-typed-om",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1278697",
"mozPosition": "worth prototyping",
"mozPositionDetail": "This specification provides an easier way to manipulate the CSS object model.",
"mozPositionIssue": 93,
"org": "W3C",
"title": "CSS Typed OM",
"url": "https://drafts.css-houdini.org/css-typed-om-1"
},
{
"ciuName": null,
"description": "This specification defines a HTTP/2 frame type to allow clients to inform the server of their cache's contents. Servers can then use this to inform their choices of what to push to clients.",
"id": "http-cache-digest",
"mozBugUrl": null,
"mozPosition": "non-harmful",
"mozPositionDetail": "This is experimental technology that might improve the use of server push by giving servers information about what is cached. It is still unclear how much this might improve performance; more experimentation is likely necessary to prove this out.",
"mozPositionIssue": 131,
"org": "IETF",
"title": "Cache Digests for HTTP/2",
"url": "https://tools.ietf.org/html/draft-ietf-httpbis-cache-digest"
},
{
"ciuName": null,
"description": "This document defines an imperative mechanism which allows web developers to instruct a user agent to clear a site's locally stored data related to a host.",
"id": "clear-site-data",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1268889",
"mozPosition": "worth prototyping",
"mozPositionDetail": "This feature is useful for sites to be able to recover from mistakes in deployment of certain web technologies like Service Workers, and thus makes them more confident about deploying such technology.",
"mozPositionIssue": 90,
"org": "W3C",
"title": "Clear Site Data",
"url": "https://w3c.github.io/webappsec-clear-site-data/"
},
{
"ciuName": null,
"description": "This document defines a set of JavaScript APIs to compress and decompress streams of binary data.",
"id": "compression-streams",
"mozBugUrl": null,
"mozPosition": "worth prototyping",
"mozPositionDetail": "This provides a small API wrapper around compression formats implementations already have to support and hopefully leads to more things being compressed due to ease-of-use.",
"mozPositionIssue": 207,
"org": "Proposal",
"title": "Compression Streams",
"url": "https://wicg.github.io/compression/"
},
{
"ciuName": null,
"description": "This draft defines additions to CSSOM to make CSSStyleSheet objects directly constructable, along with a way to use them in DocumentOrShadowRoots.",
"id": "construct-stylesheets",
"mozBugUrl": null,
"mozPosition": "worth prototyping",
"mozPositionDetail": null,
"mozPositionIssue": 103,
"org": "Proposal",
"title": "Constructable Stylesheet Objects",
"url": "https://wicg.github.io/construct-stylesheets/"
},
{
"ciuName": null,
"description": "This proposal adds an API for prompting and querying the user\u2019s contacts for one or more items with a handful of contact properties.",
"id": "contact-picker",
"mozBugUrl": null,
"mozPosition": "defer",
"mozPositionDetail": "This API innnovates in some ways beyond several previous Contacts APIs, though uses different properties than HTML autofill field names.",
"mozPositionIssue": 153,
"org": "Proposal",
"title": "Contact Picker API",
"url": "https://wicg.github.io/contact-api/spec/"
},
{
"ciuName": null,
"description": "An asynchronous Javascript cookies API for documents and workers",
"id": "cookie-store",
"mozBugUrl": null,
"mozPosition": "defer",
"mozPositionDetail": "This API provides better access to cookies. However, the improvements also expand access to cookie metadata and the interactions with privacy features like the Storage Access API are unclear. Work on improving cookie interoperability, which is ongoing, might be needed before an assessment can be made.",
"mozPositionIssue": 94,
"org": "Proposal",
"title": "Cookie Store API",
"url": "https://wicg.github.io/cookie-store/"
},
{
"ciuName": null,
"description": "This document defines a mechanism for reporting browser crashes to site owners through the use of the Reporting API.",
"id": "crash-reporting",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1607364",
"mozPosition": "worth prototyping",
"mozPositionDetail": "This seems like it could be a useful addition to the reporting API. We're not yet confident what level of user consent is needed, but we can experiment with that without changes to the specification.",
"mozPositionIssue": 288,
"org": "Proposal",
"title": "Crash Reporting",
"url": "https://wicg.github.io/crash-reporting/"
},
{
"ciuName": null,
"description": "This specification describes an imperative API enabling a website to request a user\u2019s credentials from a user agent, and to help the user agent correctly store user credentials for future use.",
"id": "credman",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1156047",
"mozPosition": "defer",
"mozPositionDetail": "Development of the specification seems to have stalled and it's also not a priority for Mozilla.",
"mozPositionIssue": 172,
"org": "W3C",
"title": "Credential Management Level 1",
"url": "https://w3c.github.io/webappsec-credential-management/"
},
{
"ciuName": null,
"description": "Blocklist certain opaque responses based on MIME type and return an 'emptied' response instead.",
"id": "corb",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1459357",
"mozPosition": "non-harmful",
"mozPositionDetail": "While this is an important aspect of a robust Spectre-defense, we would like to see a safelist-based approach pursued, e.g., <a href=\"https://github.com/annevk/orb\">Opaque Response Blocking</a>.",
"mozPositionIssue": 81,
"org": "Proposal",
"title": "Cross-Origin Read Blocking (CORB)",
"url": "https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md"
},
{
"ciuName": null,
"description": "Add support for Curve25519 algorithms in the Web Cryptography API, namely the signature algorithm Ed25519 and the key agreement algorithm X25519.",
"id": "webcrypto-curve25519",
"mozBugUrl": "",
"mozPosition": "worth prototyping",
"mozPositionDetail": "We are in favor of this work, but would like to see it have a path to standardization. When doing that, it may be worth reconsidering some of the \"no seatbelts\" aspects of WebCrypto more generally, and perhaps adding other algorithms as well.",
"mozPositionIssue": 271,
"org": "Proposal",
"title": "Curve25519 in the Web Cryptography API",
"url": "https://github.com/tQsW/webcrypto-curve25519"
},
{
"ciuName": null,
"description": "A way to create new HTML elements implemented through JavaScript.",
"id": "custom-elements",
"mozBugUrl": null,
"mozPosition": "worth prototyping",
"mozPositionDetail": "A welcome successor to XBL!",
"mozPositionIssue": 60,
"org": "WHATWG",
"title": "Custom elements",
"url": "https://html.spec.whatwg.org/multipage/custom-elements.html#custom-elements"
},
{
"ciuName": null,
"description": "This will allow custom elements to have \"default\" accessibility semantics, analogous to how built-in elements have \"implicit\" or \"native\" semantics.",
"id": "custom-elements-a11y",
"mozBugUrl": null,
"mozPosition": "worth prototyping",
"mozPositionDetail": "This is an important addition to custom elements as otherwise they'd have to publicly expose their internals in order to get accessibility correct.",
"mozPositionIssue": 201,
"org": "WHATWG",
"title": "Default Accessibility Semantics for Custom Elements",
"url": "https://github.com/whatwg/html/pull/4658"
},
{
"ciuName": null,
"description": "This document defines a simple mechanism for encrypting the Server Name Indication for TLS 1.3.",
"id": "tls-esni",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1494901",
"mozPosition": "important",
"mozPositionDetail": "This feature enables encryption of the server name in connection attempts. It provides much-needed protection against attempts by network observers to see what people are doing. This work is complementary with efforts to encrypt DNS requests that we are also driving.",
"mozPositionIssue": 139,
"org": "IETF",
"title": "Encrypted Server Name Indication for TLS 1.3",
"url": "https://tools.ietf.org/html/draft-ietf-tls-esni"
},
{
"ciuName": null,
"description": "This specification defines a mechanism that allows developers to selectively enable and disable use of various browser features and APIs.",
"id": "feature-policy",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1390801",
"mozPosition": "worth prototyping",
"mozPositionDetail": "Mozilla's primary interest in this specification is in the delegation of permissions to third-party contexts, and in particular permissions that might require the user to make a choice. To that end we are willing to prototype and ship the allow attribute, but given this reduction in scope the remaining functionality needs to be reevaluated in terms of naming and applicability.",
"mozPositionIssue": 24,
"org": "Proposal",
"title": "Feature Policy",
"url": "https://wicg.github.io/feature-policy/"
},
{
"ciuName": null,
"description": "This document defines a set of Fetch metadata request headers that aim to provide servers with enough information to make a priori decisions about whether or not to service a request based on the way it was made, and the context in which it will be used.",
"id": "fetch-metadata",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1508292",
"mozPosition": "worth prototyping",
"mozPositionDetail": "This gives servers useful context about requests that can be used to mitigate various security issues. The existing setup for embed/object elements gave some tough design challenges for this feature that were satisfactorily resolved. (There's also a reasonable expectation to be able to simplify these elements going forward.)",
"mozPositionIssue": 88,
"org": "W3C",
"title": "Fetch Metadata Request Headers",
"url": "https://github.com/w3c/webappsec-fetch-metadata"
},
{
"ciuName": null,
"description": "This proposal gives web applications a way to register their ability to handle (read, stream, edit) files with given MIME types and/or file extensions.",
"id": "wicg-file-handling",
"mozBugUrl": null,
"mozPosition": "defer",
"mozPositionDetail": "Not far enough along to properly evaluate.",
"mozPositionIssue": 158,
"org": "Proposal",
"title": "File Handling",
"url": "https://github.com/WICG/file-handling/blob/master/explainer.md"
},
{
"ciuName": null,
"description": "An API to enable objects other than built-in form control elements to participate in form submission, form validation, and so on.",
"id": "form-participation-api",
"mozBugUrl": [
"https://bugzilla.mozilla.org/show_bug.cgi?id=1518442",
"https://bugzilla.mozilla.org/show_bug.cgi?id=1552327"
],
"mozPosition": "worth prototyping",
"mozPositionDetail": "These propose what seems likely to be a useful addition to allow custom controls to participate in form validation and submission.",
"mozPositionIssue": 150,
"org": "WHATWG",
"title": "Form Particpation API",
"url": "https://github.com/whatwg/html/pull/4383"
},
{
"ciuName": null,
"description": "A proposal for using URL fragments with spaces in them to select a bit of text to highlight and scroll to",
"id": "fragmention",
"mozBugUrl": null,
"mozPosition": "worth prototyping",
"mozPositionDetail": "We feel that some of the use cases this proposal addresses are very important to address, but worry about the lack of a clear processing model and about possible compat constraints that may need implementation experience to fully understand. More details are in the position issue. See also the position on Scroll to Text Fragment, which aims to address similar use cases.",
"mozPositionIssue": 234,
"org": "Proposal",
"title": "Fragmention",
"url": "https://indieweb.org/fragmention"
},
{
"ciuName": null,
"description": "The Get Installed Related Apps API allows web apps to detect if related apps are installed on the current device.",
"id": "get-installed-related-apps",
"mozBugUrl": null,
"mozPosition": "harmful",
"mozPositionDetail": "This feature increases the fingerprinting surface of browsers without sufficient safeguards.",
"mozPositionIssue": 213,
"org": "Proposal",
"title": "Get Installed Related Apps API",
"url": "https://wicg.github.io/get-installed-related-apps/spec"
},
{
"ciuName": "imports",
"description": "HTML Imports are a way to include and reuse HTML documents in other HTML documents.",
"id": "html-imports",
"mozBugUrl": null,
"mozPosition": "harmful",
"mozPositionDetail": "Mozilla anticipated that JavaScript modules would change the landscape here and would rather invest in evolving that, e.g., through HTML Modules. Having a single mechanism to deal with dependencies rather than several, potentially conflicting systems, seems preferable.",
"mozPositionIssue": 60,
"org": "W3C",
"title": "HTML Imports",
"url": "https://www.w3.org/TR/2016/WD-html-imports-20160225"
},
{
"ciuName": null,
"description": "An extension of the ES6 Script Modules system to include HTML Modules. These will allow web developers to package and access declarative content from script in a way that allows for good componentization and reusability, and integrates well into the existing ES6 Modules infrastructure.",
"id": "html-modules",
"mozBugUrl": null,
"mozPosition": "worth prototyping",
"mozPositionDetail": null,
"mozPositionIssue": 137,
"org": "WHATWG",
"title": "HTML Modules",
"url": "https://github.com/w3c/webcomponents/blob/gh-pages/proposals/html-modules-explainer.md"
},
{
"ciuName": null,
"description": "<video>.requestVideoFrameCallback() allows web authors to be notified when a frame has been presented for composition.",
"id": "requestVideoFrameCallback",
"mozBugUrl": null,
"mozPosition": "worth prototyping",
"mozPositionDetail": "This is intended to allow web authors to do efficient per-video-frame processing of video, such as video processing and painting to a canvas, video analysis, or synchronization with external audio sources.",
"mozPositionIssue": 250,
"org": "Proposal",
"title": "HTMLVideoElement.requestVideoFrameCallback()",
"url": "https://wicg.github.io/video-rvfc"
},
{
"ciuName": null,
"description": "This document defines two independent HTTP Cache-Control extensions that allow control over the use of stale responses by caches. This document is not an Internet Standards Track specification; it is published for informational purposes.",
"id": "http-stale-controls",
"mozBugUrl": null,
"mozPosition": "worth prototyping",
"mozPositionDetail": "The stale-while-revalidate cache control extension appears to provide improved user experience with no obvious drawbacks. We take no position on the other mechanisms in RFC 5861 at this time.",
"mozPositionIssue": 144,
"org": "Proposal",
"title": "HTTP Cache-Control Extensions for Stale Content",
"url": "https://tools.ietf.org/html/rfc5861"
},
{
"ciuName": "client-hints-dpr-width-viewport",
"description": "An increasing diversity of Web-connected devices and software capabilities has created a need to deliver optimized content for each device. This specification defines an extensible and configurable set of HTTP request header fields, colloquially known as Client Hints, to address this. They are intended to be used as input to proactive content negotiation; just as the Accept header field allows user agents to indicate what formats they prefer, Client Hints allow user agents to indicate device and agent specific preferences.",
"id": "http-client-hints",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=935216",
"mozPosition": "non-harmful",
"mozPositionDetail": "Architecturally, Mozilla prefers client-side solutions for retrieving alternate versions of content, such as the HTML <picture> tag. Despite these architectural preferences, we find that Client-Hints do not present a concrete harm to the web or to its users. ",
"mozPositionIssue": 79,
"org": "IETF",
"title": "HTTP Client Hints",
"url": "https://tools.ietf.org/html/draft-ietf-httpbis-client-hints"
},
{
"ciuName": null,
"description": "This specification defines an API that allows websites to convert from a given code value to a valid key value that can be shown to the user to identify the given key. The conversion from code to key is based on the user\u2019s currently selected keyboard layout. It is intended to be used by web applications that want to treat the keyboard as a set of buttons and need to describe those buttons to the user.",
"id": "keyboard-map",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1469017",
"mozPosition": "harmful",
"mozPositionDetail": "We're concerned that this exposes keyboard layouts, which seem likely to be a significant source of fingerprinting data, in a way that does not require any user interaction.",
"mozPositionIssue": 300,
"org": "Proposal",
"title": "Keyboard Map",
"url": "https://wicg.github.io/keyboard-map/"
},
{
"ciuName": "loading-lazy-attr",
"description": "Enabling images to be fetched at a later time, when the user is likely to look at them.",
"id": "loading-lazy-attr",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1542784",
"mozPosition": "worth prototyping",
"mozPositionDetail": "As currently scoped in the HTML pull request this is a reasonable addition to how images are fetched. (Note that the scope on Can I use is slightly bigger. Frames are likely a reasonable addition, but have their own set of design challenges.)",
"mozPositionIssue": 151,
"org": "WHATWG",
"title": "Lazy loading (of images)",
"url": "https://github.com/whatwg/html/pull/3752"
},
{
"ciuName": null,
"description": "This document updates RFC 6761 with the goal of ensuring that \"localhost\" can be safely relied upon as a name for the local host's loopback interface. To that end, stub resolvers are required to resolve localhost names to loopback addresses. Recursive DNS servers are required to return \"NXDOMAIN\" when queried for localhost names, making non-conformant stub resolvers more likely to fail and produce problem reports that result in updates. Together, these requirements would allow applications and specifications to join regular users in drawing the common-sense conclusions that \"localhost\" means \"localhost\", and doesn't resolve to somewhere else on the network.",
"id": "let-localhost-be-localhost",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1220810",
"mozPosition": "worth prototyping",
"mozPositionDetail": "The proposal, to the extent it applies to browsers, is to hardcode localhost to always resolve to a loopback address instead of invoking the resolver library to perform such translation. Since browsers (including Firefox) treat files hosted on localhost to be more privileged than remote content, this proposal seems to be a good belt-and-suspenders approach to prevent certain exploits.",
"mozPositionIssue": 121,
"org": "IETF",
"title": "Let 'localhost' be localhost.",
"url": "https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost"
},
{
"ciuName": null,
"description": "This document defines a web platform API that lets websites gain write access to the native file system. It builds on [FILE-API], but adds lots of new functionality on top.",
"id": "native-file-system",
"mozBugUrl": null,
"mozPosition": "defer",
"mozPositionDetail": "The ability to read and write from the filesystem is potentially very dangerous. We will need to carefully consider any solution in light of the security and privacy implications. We recognize that the spec authors take this issue seriously, but we are concerned that any solution will increase the risk of security incidents more than we are willing to tolerate. Right now, there isn't enough detail in the specification to make an assessment of these risks, so we will defer our decision until we have more information.",
"mozPositionIssue": 154,
"org": "Proposal",
"title": "Native File System",
"url": "https://wicg.github.io/native-file-system/"
},
{
"ciuName": "netinfo",
"description": "The Network Information API enables web applications to access information about the network connection in use by the device.",
"id": "netinfo",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1057169",
"mozPosition": "harmful",
"mozPositionDetail": "This API provides information about a client's network connection, which allows sites to obtain additional information about clients and their environment. It is better that sites use methods that dynamically adapt to available bandwidth, as that is more accurate and likely to be applicable in the moment.",
"mozPositionIssue": 117,
"org": "Proposal",
"title": "Network Information API",
"url": "https://wicg.github.io/netinfo"
},
{
"ciuName": null,
"description": "Origin isolation refers to segregating cross-origin documents into separate agent clusters.",
"id": "domenic-origin-isolation",
"mozBugUrl": null,
"mozPosition": "worth prototyping",
"mozPositionDetail": "Letting developers opt out of document.domain and reduce the potential size of their agent cluster allows user agents to balance security, performance, and resource management.",
"mozPositionIssue": 244,
"org": "Proposal",
"title": "Origin Isolation",
"url": "https://github.com/WICG/origin-isolation"
},
{
"ciuName": null,
"description": "This specification defines a delivery mechanism for a number of policies which are to be applied to an entire origin. It compliments header-based delivery mechanisms for existing policies (Content Security Policy, Referrer Policy, etc).",
"id": "origin-policy",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1508290",
"mozPosition": "worth prototyping",
"mozPositionDetail": "Giving developers the ability to set policies for an entire origin is a powerful new primitive that will benefit security of applications as well as performance due to the ability to bypass CORS preflights. The renewed effort to make this happen takes a strong anti-tracking stance that is in line with our efforts around privacy in Fetch, such as isolating the HTTP cache. Given this, it seems worth figuring out if this can be made viable.",
"mozPositionIssue": 160,
"org": "Proposal",
"title": "Origin Policy",
"url": "https://wicg.github.io/origin-policy/"
},
{
"ciuName": null,
"description": "This specification defines capabilities that enable Web applications to handle requests for payment.",
"id": "payment-handler",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1465682",
"mozPosition": "defer",
"mozPositionDetail": "We believe this is worth working on because it is an important part of making an open and secure payments ecosystem for the web. At the same time, we're quite concerned about the tradeoffs being made between extensibility and the user interface that is best for users' security, and we might take a substantially different position from the current direction of that work, such as by limiting the ability for payment handlers to show UI when invoked from another page, or even by standardizing a set of handlers instead of having an extensible handler mechanism. So our eventual position will depend on how these tradeoffs are made.",
"mozPositionIssue": 23,
"org": "W3C",
"title": "Payment Handler API",
"url": "https://w3c.github.io/payment-handler"
},
{
"ciuName": null,
"description": "This specification defines the machine-readable manifest file, known as a payment method manifest, describing how a payment method participates in the Web Payments ecosystem, and how such files are to be used.",
"id": "payment-method-manifest",
"mozBugUrl": null,
"mozPosition": "defer",
"mozPositionDetail": "We'd like to defer this for the same reasons as Payment Handler, given that it is closely related.",
"mozPositionIssue": 22,
"org": "W3C",
"title": "Payment Method Manifest",
"url": "https://w3c.github.io/payment-method-manifest"
},
{
"ciuName": null,
"description": "This specification describes a method that enables web applications to synchronize data in the background.",
"id": "periodic-background-sync",
"mozBugUrl": null,
"mozPosition": "harmful",
"mozPositionDetail": "We're concerned that this feature would allow users to be tracked across networks (leaking private information about location and IP address and how they change over time), and that it would allow script execution and resource consumption when it isn't clear to the user that they're interacting with the site. We might reconsider this position given evidence that these concerns can be safely addressed, however, addressing them for periodic background sync appears substantially harder than doing so for one-off background sync.",
"mozPositionIssue": 214,
"org": "Proposal",
"title": "Periodic Background Synchronization",
"url": "https://github.com/WICG/BackgroundSync/blob/master/explainers/periodicsync-explainer.md"
},
{
"ciuName": "permissions-api",
"description": "The Permissions Standard defines common infrastructure for other specifications that need to interact with browser permissions. It also defines an API to allow web applications to query and request changes to the status of a given permission.",
"id": "permissions",
"mozBugUrl": null,
"mozPosition": "important",
"mozPositionDetail": "Mozilla believes that the ability to work with user permissions is critical for user agency. There are certain aspects of the API that are not suitable for the permissions model used in Firefox and so we would like to work on improving several aspects of the API. In particular, we think that the way that status of permissions needs to more accurately reflect the different states that exist or could exist. We also think that the interactions with Feature Policy need to be better clarified. We're committed to fixing this, because permissions has become critical in making the web a more capable platform and it is important to ensure that we preserve user control over their online experience.",
"mozPositionIssue": 19,
"org": "W3C",
"title": "Permissions",
"url": "https://w3c.github.io/permissions/"
},
{
"ciuName": null,
"description": "This specification intends to provide APIs to allow websites to create a floating video window always on top of other windows so that users may continue consuming media while they interact with other content sites, or applications on their device.",
"id": "picture-in-picture",
"mozBugUrl": null,
"mozPosition": "defer",
"mozPositionDetail": "We ship Picture-in-Picture (PiP) as a feature in Firefox, but without exposing a JavaScript API. We are evaluating if our PiP UI affordances are sufficient for users and web applications. In the future, we may reconsider exposing the API, which is why we have chosen to 'defer'.",
"mozPositionIssue": 72,
"org": "Proposal",
"title": "Picture-in-Picture",
"url": "https://wicg.github.io/picture-in-picture/"
},
{
"ciuName": null,
"description": "Powerful web applications would like to exchange data with native applications via the OS clipboard (copy-paste). The existing Web Platform has a high-level API that supports the most popular standardized data types (text, image, rich text) across all platforms. However, this API does not scale to the long tail of specialized formats. In particular, non-web-standard formats like TIFF (a large image format), and proprietary formats like .docx (a document format), are not supported by the current Web Platform. Raw Clipboard Access aims to provide a low-level API solution to this problem, by implementing copying and pasting of data with any arbitrary Clipboard type, without encoding and decoding.",
"id": "raw-clipboard-access",
"mozBugUrl": null,
"mozPosition": "harmful",
"mozPositionDetail": "The current proposal has significant risks of attacks on native applications. Some of these attacks may be mitigated by pickling or other similar solutions. If such a solution is incorporated, we would be willing to reevaluate this proposal.",
"mozPositionIssue": 206,
"org": "Proposal",
"title": "Raw Clipboard Access",
"url": "https://github.com/WICG/raw-clipboard-access/"
},
{
"ciuName": null,
"description": "This document defines a generic reporting framework which allows web developers to associate a set of named reporting endpoints with an origin. Various platform features can use these endpoints to deliver feature-specific reports in a consistent manner.",
"id": "reporting",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1620573",
"mozPosition": "worth prototyping",
"mozPositionDetail": "This is a reasonable generalization of the CSP reporting mechanism that allows more features to adopt it.",
"mozPositionIssue": 104,
"org": "W3C",
"title": "Reporting API",
"url": "https://w3c.github.io/reporting/"
},
{
"ciuName": null,
"description": "A way to force an embedded document and descendants (regardless of origin) into each having their own agent/event loop.",
"id": "documentaccess",
"mozBugUrl": null,
"mozPosition": "harmful",
"mozPositionDetail": "Changing control flow of cross-origin documents without their consent is not something we should expand upon (i.e., beyond what sandboxing allows) as it could enable attack vectors. Furthermore, forcing same-origin documents in the same browsing context group to be in different agents is a major architectural change and this does not offer enough advantages to make such a change.",
"mozPositionIssue": 197,
"org": "Proposal",
"title": "Restricting Document Access of Same Origin Documents",
"url": "https://github.com/dtapuska/documentaccess"
},
{
"ciuName": null,
"description": "Reducing the scope of cookies by including the URL scheme in their keying material as well as reducing the lifetime of non-secure cookies.",
"id": "scheming-cookies",
"mozBugUrl": null,
"mozPosition": "important",
"mozPositionDetail": "Reducing the scope of cookies along this axis is a major win.",
"mozPositionIssue": 298,
"org": "Proposal",
"title": "Scheme-Bound Cookies",
"url": "https://github.com/mikewest/scheming-cookies"
},
{
"ciuName": null,
"description": "This document specifies an API that allows web applications to request a screen wake lock. Under the right conditions, and if allowed, the screen wake lock prevents the system from turning off a device's screen.",
"id": "screen-wake-lock",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=158955",
"mozPosition": "worth prototyping",
"mozPositionDetail": "As the scope of the specification has been reduced to screen wake locks, it's worth prototyping this API in a manner that restricts it to foreground first-party content. Additionally, the API appears flexible enough that a permission grant can be performed asynchronously, allowing us to evaluate the most appropriate permission model should we choose to ship this API in the future. As the API allows the capability to be revoked at any time, we can also prototype eagerly granting, notifying the user what's going on, and allowing users to disable the capability entirely - either per origin, or globally through a browser setting. There is a risk that sites could abuse the API for the sake of engagement, which could unnecessarily drain a device's battery. It could also be a nuisance or be used for social engineering attacks: such as disabling the system's ability to password-lock a device when the screen doesn't switch off if the user leaves their device unattended. Prototyping this capability would allow us to further evaluate how to best mitigate the aforementioned concerns.",
"mozPositionIssue": 210,
"org": "W3C",
"title": "Screen Wake Lock API",
"url": "https://w3c.github.io/wake-lock/"
},
{
"ciuName": null,
"description": "A proposal for extending URL fragment syntax with a list of text bits to highlight and scroll to",
"id": "scroll-to-text-fragment",
"mozBugUrl": null,
"mozPosition": "non-harmful",
"mozPositionDetail": "We feel that some of the use cases this proposal addresses are very important to address, but that this specific proposal introduces various harmful aspects in the process of addressing them. We feel that it would be worth prototyping a proposal with those harmful aspects removed. More details are in the position issue. See also the position on Fragmention, which aims to address similar use cases.",
"mozPositionIssue": 194,
"org": "Proposal",
"title": "Scroll to Text Fragment",
"url": "https://github.com/WICG/ScrollToTextFragment"
},
{
"ciuName": null,
"description": "A use of TLS Exported Authenticators is described which enables HTTP/2 clients and servers to offer additional certificate-based credentials after the connection is established. The means by which these credentials are used with requests is defined.",
"id": "http2-secondary-certs",
"mozBugUrl": null,
"mozPosition": "worth prototyping",
"mozPositionDetail": "This specification enables client authentication in HTTP/2, which is of some benefit. However, it is the server authentication that is most interesting from a privacy perspective. There are some challenges that would need to be worked through before this could be deployed in anything other than an experiment.",
"mozPositionIssue": 175,
"org": "IETF",
"title": "Secondary Certificate Authentication in HTTP/2",
"url": "https://tools.ietf.org/html/draft-ietf-httpbis-http2-secondary-certs"
},
{
"ciuName": null,
"description": "The Serial API provides a way for websites to read and write from a serial device through script. Such an API would bridge the web and the physical world, by allowing documents to communicate with devices such as microcontrollers, 3D printers, and other serial devices. There is also a companion explainer document.",
"id": "webserial",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=webserial",
"mozPosition": "harmful",
"mozPositionDetail": "Devices that offer serial interfaces often expose powerful, low-level functions over the interface with little or no authentication. Exposing that sort of capability to the web without adequate safeguards presents a significant threat to those devices.",
"mozPositionIssue": 336,
"org": "Proposal",
"title": "Serial API",
"url": "https://wicg.github.io/serial"
},
{
"ciuName": null,
"description": "This document specifies the \"SVCB\" and \"HTTPSSVC\" DNS resource record types to facilitate the lookup of information needed to make connections for origin resources, such as for HTTPS URLs. SVCB records allow an origin to be served from multiple network locations, each with associated parameters (such as transport protocol configuration and keying material for encrypting TLS SNI). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPSSVC DNS RR is a variation of SVCB for HTTPS and HTTP origins. By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy.",
"id": "dnsop-svcb-httpssvc",
"mozBugUrl": null,
"mozPosition": "worth prototyping",
"mozPositionDetail": "While there are some details of the proposal that may require refining, we beleive that this is a promising approach to support Encrypted SNI, and may help improve user experience with HTTP/3.",
"mozPositionIssue": 208,
"org": "IETF",
"title": "Service binding and parameter specification via the DNS (DNS SVCB and HTTPSSVC)",
"url": "https://tools.ietf.org/html/draft-ietf-dnsop-svcb-httpssvc"
},
{
"ciuName": null,
"description": "A way to give a node in the DOM a hidden subtree in which the children of the node can be inserted.",
"id": "shadow-trees",
"mozBugUrl": null,
"mozPosition": "worth prototyping",
"mozPositionDetail": "A welcome successor to XBL!",
"mozPositionIssue": 60,
"org": "WHATWG",
"title": "Shadow trees (formerly known as Shadow DOM)",
"url": "https://dom.spec.whatwg.org/#shadow-trees"
},
{
"ciuName": null,
"description": "This document specifies how a server can send an HTTP request/ response pair, known as an exchange, with signatures that vouch for that exchange's authenticity. These signatures can be verified against an origin's certificate to establish that the exchange is authoritative for an origin even if it was transferred over a connection that isn't. The signatures can also be used in other ways described in the appendices. These signatures contain countermeasures against downgrade and protocol-confusion attacks.",
"id": "http-origin-signed-responses",
"mozBugUrl": null,
"mozPosition": "harmful",
"mozPositionDetail": "Mozilla has concerns about the shift in the web security model required for handling web-packaged information. Specifically, the ability for an origin to act on behalf of another without a client ever contacting the authoritative server is worrisome, as is the removal of a guarantee of confidentiality from the web security model (the host serving the web package has access to plain text). We recognise that the use cases satisfied by web packaging are useful, and would be likely to support an approach that enabled such use cases so long as the foregoing concerns could be addressed.",
"mozPositionIssue": 29,
"org": "Proposal",
"title": "Signed HTTP Exchanges",
"url": "https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses"
},
{
"ciuName": "",
"description": "The Storage Access API provides a means for authenticated cross-site embeds to check their blocking status and request access to storage if they are blocked.",
"id": "storage-access-api",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1469714",
"mozPosition": "worth prototyping",
"mozPositionDetail": "In our current efforts to limit the impact of cross-site tracking there are cases where we may unintentionally break parts of web pages that users depend on. The storage access API provides a programmatic way for affected embedded content to fix these types of broken experiences for the user. Also, in our upcoming efforts to limit the potential capabilities for unknown third-parties to track the user, we would like to continue to restrict the storage capabilities of the third-party context. The storage access API similarly provides a programmatic path for the embedded widgets which cannot work correctly without access to their data. It isn't an ideal solution, for example our implementation falls back to prompting the user if it cannot automatically determine whether access should be granted or not, but it is a step in the right direction in the game of reversing the current defaults of the web, that is granting permissive storage access rights to all third-party contexts unconditionally.",
"mozPositionIssue": 280,
"org": "Proposal",
"title": "Storage Access API",
"url": "https://github.com/privacycg/storage-access"
},
{
"ciuName": "streams",
"description": "This specification provides APIs for creating, composing, and consuming streams of data that map efficiently to low-level I/O primitives.",
"id": "streams",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1128959",
"mozPosition": "worth prototyping",
"mozPositionDetail": "Streams are an important building block for many APIs, in particular around networking and media.",
"mozPositionIssue": 70,
"org": "WHATWG",
"title": "Streams",
"url": "https://streams.spec.whatwg.org"
},
{
"ciuName": null,
"description": "This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header fields. It is intended for use by specifications of new HTTP header fields that wish to use a common syntax that is more restrictive than traditional HTTP field values.",
"id": "structured-headers",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1631722",
"mozPosition": "worth prototyping",
"mozPositionDetail": "Use of structured headers promises to improve consistency and interoperability of new HTTP header fields. Depending on further security analysis, we may upgrade this feature to 'important' in the future.",
"mozPositionIssue": 256,
"org": "IETF",
"title": "Structured Headers for HTTP",
"url": "https://tools.ietf.org/html/draft-ietf-httpbis-header-structure"
},
{
"ciuName": null,
"description": "Serializing and deserializing JavaScript Error objects.",
"id": "errors-structured-cloning",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1556604",
"mozPosition": "worth prototyping",
"mozPositionDetail": "Good extension to the object serialization algorithm (StructuredSerializeInternal) as currently there is no way to serialize errors.",
"mozPositionIssue": 165,
"org": "WHATWG",
"title": "Structured cloning of errors",
"url": "https://github.com/whatwg/html/issues/4268"
},
{
"ciuName": null,
"description": "This document specifies the Privacy Pass protocol for anonymously authorizing clients with services on the Internet. Note to Readers Source for this draft and an issue tracker can be found at https://github.com/grittygrease/draft-privacy-pass [1].",
"id": "privacy-pass",
"mozBugUrl": null,
"mozPosition": "defer",
"mozPositionDetail": "This protocol provides a way to achieve certain important goals, such as denial of service mitigation, without also creating tracking mechanisms. As such, we are very supportive of the goal. However, we will defer making a firm position until the protocol and the novel cryptographic primitives it relies on have had more thorough security analysis.",
"mozPositionIssue": null,
"org": "Proposal",
"title": "The Privacy Pass Protocol",
"url": "https://tools.ietf.org/html/draft-privacy-pass"
},
{
"ciuName": null,
"description": "The WebTransport Protocol Framework enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport. It consists of a set of individual protocols that are safe to expose to untrusted applications, combined with a model that allows them to be used interchangeably. This document defines the overall requirements on the protocols used in WebTransport, as well as the common features of the protocols, support for some of which may be optional.",
"id": "webtransport",
"mozBugUrl": null,
"mozPosition": "worth prototyping",
"mozPositionDetail": "We are generally in support of a mechanism that addresses the use cases implied by this solution document. While major questions remain open at this time -- notably, multiplexing, the API surface, and available statistics -- we think that prototyping the proposed solution as details become more firm would be worthwhile. We would like see the new WebSocketStream and WebTransport stream APIs to be developed in concert with each other, so as to share as much design as possible.",
"mozPositionIssue": 167,
"org": "Proposal",
"title": "The WebTransport Protocol Framework",
"url": "https://tools.ietf.org/html/draft-vvv-webtransport-overview"
},
{
"ciuName": null,
"description": "In Transport Layer Security (TLS) handshakes, certificate chains often take up the majority of the bytes transmitted. This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips.",
"id": "tls-certificate-compression",
"mozBugUrl": null,
"mozPosition": "worth prototyping",
"mozPositionDetail": "Compression of certificates should provide some performance advantages.",
"mozPositionIssue": 96,
"org": "IETF",
"title": "Transport Layer Security (TLS) Certificate Compression",
"url": "https://tools.ietf.org/html/draft-ietf-tls-certificate-compression"
},
{
"ciuName": null,
"description": "This document is an explainer for a potential future web platform API that allows propagating trust across sites, using the Privacy Pass protocol as an underlying primitive.",
"id": "trust-token",
"mozBugUrl": null,
"mozPosition": "defer",
"mozPositionDetail": "This API depends on the Privacy Pass protocol, for which we have deferred our position statement.",
"mozPositionIssue": null,
"org": "Proposal",
"title": "Trust Token API",
"url": "https://github.com/WICG/trust-token-api/blob/master/README.md"
},
{
"ciuName": null,
"description": "An API that allows applications to lock down powerful APIs to only accept non-spoofable, typed values in place of strings to prevent vulnerabilities caused by using these APIs with attacker-controlled inputs.",
"id": "trusted-types",
"mozBugUrl": null,
"mozPosition": "non-harmful",
"mozPositionDetail": "The API could be used to harden sites against certain cross-site scripting issues, but it is sufficiently complex that we are concerned that it will not be suitable for many sites.",
"mozPositionIssue": 20,
"org": "W3C",
"title": "Trusted Types",
"url": "https://w3c.github.io/webappsec-trusted-types/dist/spec"
},
{
"ciuName": null,
"description": "The QID Emoji Tag Sequences (or QID emoji, for short) have been proposed to provide a well-defined mechanism for implementations to support additional valid emoji that are not representable by Unicode characters or emoji zwj sequences. This mechanism allows for the interchange of emoji whose meaning is discoverable, and which should be correctly parsed by all conformant implementations (although only displayed by implementations that support it). The meaning of each of these valid emoji is established by reference to a Wikidata QID.",
"id": "unicode-emoji-qid",
"mozBugUrl": null,
"mozPosition": "harmful",
"mozPositionDetail": "Mozilla has a number of concerns about this proposal, including: (a) the lack of reference glyphs is likely to increase miscommunication between users; (b) having a formal, versioned approval process provides synchronization between implementors for adding new glyphs, and this proposal removes that; (c) QID glyphs that are later adopted into Unicode would result in duplicate encodings, perhaps in perpetuity; (d) gathering telemetry about the popularity of specific emoji for the purposes of more formal codepoint assignments may cause privacy issues and provides incumbent implementors a competitive advantage; and (e) there are no barriers to abuse of the QID system to create non-emoji characters as a general end-run around the Unicode process.",
"mozPositionIssue": 233,
"org": "Unicode",
"title": "Unicode Emoji QID",
"url": "https://www.unicode.org/review/pri408/pri408-tr51-QID.html"
},
{
"ciuName": null,
"description": "This document defines a set of Client Hints that aim to provide developers with the ability to perform agent-based content negotiation when necessary, while avoiding the historical baggage and passive fingerprinting surface exposed by the venerable \"User-Agent\" header.",
"id": "ua-client-hints",
"mozBugUrl": null,
"mozPosition": "non-harmful",
"mozPositionDetail": "Using Client Hints to deliver info derived from the User Agent header field for servers that specifically request this information may reduce the number of parties that can use this information for passively fingerprinting users. However, we could reduce this even further by freezing the User Agent string and requiring resources to actively request this information via the proposed NavigatorUAData interface JS APIs. This would also allow us to audit the callers. At this time, freezing the User Agent string without any client hints (which is not this proposal) seems worth prototyping. We look forward to learning from other vendors who implement the \"GREASE-like UA Strings\" proposal and its effects on site compatibility.",
"mozPositionIssue": 202,
"org": "Proposal",
"title": "User Agent Client Hints",
"url": "https://tools.ietf.org/html/draft-west-ua-client-hints"
},
{
"ciuName": "webauthn",
"description": "This specification defines an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications, for the purpose of strongly authenticating users. Conceptually, one or more public key credentials, each scoped to a given WebAuthn Relying Party, are created by and bound to authenticators as requested by the web application. The user agent mediates access to authenticators and their public key credentials in order to preserve user privacy. Authenticators are responsible for ensuring that no operation is performed without user consent. Authenticators provide cryptographic proof of their properties to Relying Parties via attestation. This specification also describes the functional model for WebAuthn conformant authenticators, including their signature and attestation functionality.",
"id": "webauthn",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1294514",
"mozPosition": "important",
"mozPositionDetail": "Public key cryptographic authentication is a major improvement in the fight against phishing, and we encourage all security-conscious web applications to implement authentication flows utilizing Web Authentication in the future.",
"mozPositionIssue": 163,
"org": "W3C",
"title": "Web Authentication: An API for accessing Public Key Credentials",
"url": "https://w3c.github.io/webauthn/"
},
{
"ciuName": "background-sync",
"description": "This specification describes a method that enables web applications to synchronize data in the background.",
"id": "background-sync",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1547906",
"mozPosition": "harmful",
"mozPositionDetail": "We're concerned that this feature would allow users to be tracked across networks (leaking private information about location and IP address and how they change over time), and that it would allow script execution and resource consumption when it isn't clear to the user that they're interacting with the site. We might reconsider this position given evidence that these concerns can be safely addressed.",
"mozPositionIssue": 173,
"org": "Proposal",
"title": "Web Background Synchronization",
"url": "https://wicg.github.io/BackgroundSync/spec"
},
{
"ciuName": null,
"description": "This specification describes an API that can be used to retrieve the amount of budget an origin has available for resource consuming background operations, as well as the cost associated with doing such an operation.",
"id": "budget-api",
"mozBugUrl": null,
"mozPosition": "non-harmful",
"mozPositionDetail": "This specification is being abandoned.",
"mozPositionIssue": 73,
"org": "Proposal",
"title": "Web Budget API",
"url": "https://wicg.github.io/budget-api/"
},
{
"ciuName": null,
"description": "An API that allows web applications to encode and decode audio and video",
"id": "web-codecs",
"mozBugUrl": null,
"mozPosition": "worth prototyping",
"mozPositionDetail": "This proposes a coherent set of APIs to address encoding and decoding of video and audio, which is designed to be extensible, composable, and address real use cases with good performance.",
"mozPositionIssue": 209,
"org": "Proposal",
"title": "Web Codecs",
"url": "https://github.com/WICG/web-codecs"
},
{
"ciuName": "midi",
"description": "This specification defines an API supporting the MIDI (Musical Instrument Digital Interface) protocol, enabling web applications to enumerate and select MIDI input and output devices on the client system and send and receive MIDI messages. It is intended to enable non-music MIDI applications as well as music ones, by providing low-level access to the MIDI devices available on the users' systems.",
"id": "webmidi",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=836897",
"mozPosition": "under consideration",
"mozPositionDetail": null,
"mozPositionIssue": 58,
"org": "W3C",
"title": "Web MIDI API",
"url": "https://webaudio.github.io/web-midi-api/"
},
{
"ciuName": null,
"description": "Near Field Communication (NFC) enables wireless communication between two devices at close proximity, usually less than a few centimeters. This document defines an API to enable selected use cases based on NFC technology. The current scope of this specification is NDEF. Low-level I/O operations (e.g. ISO-DEP, NFC-A/B, NFC-F) and Host-based Card Emulation (HCE) are not supported within the current scope.",
"id": "web-nfc",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1308614",
"mozPosition": "harmful",
"mozPositionDetail": "We believe Web NFC poses risks to users security and privacy because of the wide range of functionality of the existing NFC devices on which it would be supported, because there is no system for ensuring that private information is not accidentally exposed other than relying on user consent, and because of the difficulty of meaningfully asking the user for permission to share or write data when the browser cannot explain to the user what is being shared or written.",
"mozPositionIssue": 238,
"org": "Proposal",
"title": "Web NFC",
"url": "https://w3c.github.io/web-nfc/"
},
{
"ciuName": "web-share",
"description": "This specification defines an API for sharing text, links and other content to an arbitrary destination of the user's choice.The available share targets are not specified here; they are provided by the user agent. They could, for example, be apps, websites or contacts.",
"id": "web-share",
"mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=1312422",
"mozPosition": "worth prototyping",
"mozPositionDetail": "This specification defines an API that invokes sharing features of the operating system, for passing information to other applications. One risk of this is that having this as in-page user interface rather than in-browser user interface may reduce the relevance to the user of the information shown in the URL/location bar. However, given the demand for this capability it seems like it is likely worth exposing to the Web, and we support prototyping this feature.",
"mozPositionIssue": 27,
"org": "W3C",
"title": "Web Share API",
"url": "https://w3c.github.io/web-share/"
},
{
"ciuName": null,
"description": "This specification defines an API that allows websites to declare themselves asweb share targets, which can receive shared content from either the Web Share API, or system events (e.g., shares from native apps).This is a similar mechanism to navigator.registerProtocolHandler, in that it works by registering the website with the user agent, to later be invoked from another site or native application via the user agent (possibly at the discretion of the user). The difference is that registerProtocolHandler registers the handler via a programmatic API, whereas a Web Share Target is declared in the Web App Manifest, to be registered at a time of the user agent or user's choosing.",
"id": "web-share-target",
"mozBugUrl": null,
"mozPosition": "under consideration",
"mozPositionDetail": null,
"mozPositionIssue": 27,
"org": "Proposal",
"title": "Web Share Target API",
"url": "https://wicg.github.io/web-share-target/"
},
{
"ciuName": null,
"description": "This document describes a common data model and API for the Web of Things. The Web Thing Description provides a vocabulary for describing physical devices connected to the World Wide Web in a machine readable format with a default JSON encoding. The Web Thing REST API and Web Thing WebSocket API allow a web client to access the properties of devices, request the execution of actions and subscribe to events representing a change in state. Some basic Web Thing Types are provided and additional types can be defined using semantic extensions with JSON-LD. In addition to this specification there is a note on Web Thing API Protocol Bindings which proposes non-normative bindings of the Web Thing API to various existing IoT protocols. There is also a document describing Web of Things Integration Patterns which provides advice on different design patterns for integrating connected devices with the Web of Things, and where each pattern is most appropriate.",
"id": "web-thing-api",
"mozBugUrl": null,
"mozPosition": "worth prototyping",
"mozPositionDetail": null,
"mozPositionIssue": 44,
"org": "W3C",
"title": "Web Thing API",
"url": "https://iot.mozilla.org/wot/"
},
{
"ciuName": "",
"description": "Use cases about providing guarantees to users about the privacy of their WebRTC videoconferencing when the servers are not trusted but the JavaScript is.",
"id": "webrtc-nv-use-cases-trusted-js",
"mozBugUrl": null,
"mozPosition": "harmful",
"mozPositionDetail": "We believe the \"Untrusted JS\" alternative would allow browsers to provide useful guarantees to users about the security of their videoconferencing, but the \"Trusted JS\" variant would not, and seems likely to add unnecessary complexity.",
"mozPositionIssue": 205,
"org": "Proposal",
"title": "WebRTC Next Version Use Cases: Trusted JavaScript",
"url": "https://github.com/w3c/webrtc-nv-use-cases/pull/49/files"
},
{
"ciuName": "webusb",
"description": "This document describes an API for securely providing access to Universal Serial Bus devices from web pages.",
"id": "webusb",
"mozBugUrl": null,
"mozPosition": "harmful",
"mozPositionDetail": "Because many USB devices are not designed to handle potentially-malicious interactions over the USB protocols and because those devices can have significant effects on the computer they're connected to, we believe that the security risks of exposing USB devices to the Web are too broad to risk exposing users to them or to explain properly to end users to obtain meaningful informed consent. It also poses risks that sites could use USB device identity or data stored on USB devices as tracking identifiers.",
"mozPositionIssue": 100,
"org": "Proposal",
"title": "WebUSB API",
"url": "https://wicg.github.io/webusb/"
},