Proposed W3C Charter: Immersive Web Working Group

[L. David Baron]

The W3C is proposing a revised charter for:

  Immersive Web Working Group
  https://www.w3.org/2020/03/proposed-immersive-web-wg-charter.html
  https://lists.w3.org/Archives/Public/public-new-work/2020Mar/0005.html

The differences from the previous charter are:
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2018%2F09%2Fimmersive-web-wg-charter.html=https%3A%2F%2Fwww.w3.org%2F2020%2F03%2Fproposed-immersive-web-wg-charter.html

Mozilla has the opportunity to send comments or objections through
Monday, April 6.

Please reply to this thread if you think there's something we should
say as part of this charter review, or if you think we should
support or oppose it.

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: FTP protocol implementation

[ValdikSS via dev-platform]

Just a random Joe here, but I'd like to vote *against removing FTP support*. 
FTP is still widely used, its easy to configure and to use file transfer 
protocol. Despite its age, there still aren't really any proper full-featured 
and well-supported alternatives for FTP, one of the reason is because FTP is 
universally supported in OS and browsers while other protocols are not, and 
removing FTP support from Firefox removes "old and ugly" protocol without 
introducing any alternative for it, reducing the software functionality for end 
user.

The main advantage of the protocol is its design for file transfer only. Unlike 
more general and complex protocols like HTTP, FTP does not require for the 
administrator to setup and configure multiple complex software (web server + 
application server/interpreter + file sharing software on top of it) to perform 
one simple thing: file transfer. You can't upload whole folder without complex 
hacks via HTTP, while FTP allows to do that in one click.

File transfer with FTP:

  * Easy software setup, lots of mature server and client software for any 
platform
  * Upload privileges could be given as easy as sharing the link
  * You can download and upload whole folders
  * You can navigate through folders, download and upload files and folders 
with stock Unix and Windows console and graphical software

File transfer with HTTP:

  * Complex software setup: web server + special third-party file transfer 
software, which does not conform to any specification
  * Could not be properly used outside of web browsers
  * No functionality to download multiple files at once, only file-by-file
  * No functionality to download or upload folders

One of the argument against FTP is that it's unsecure. The plain FTP, just as 
HTTP, does not have encryption, but there's HTTPS alternative for FTP — FTPS, 
which is a TLS layer on top of FTP. I believe it could be easily implemented in 
Firefox. There's a bug for adding FTPS support which has been filled 19 (!) 
years ago
https://bugzilla.mozilla.org/show_bug.cgi?id=85464

I guess It would be acceptable if Mozilla remove FTP support but introduce it's 
alternative, WebDAV for example. WebDAV is a file transfer protocol on top of 
HTTP. It provides functionality similar to FTP, but it's not popular due to 
very limited software support (both client and server).

I ask you to consider not to remove FTP support. Despite its problems, the 
protocol still does what it is designed to do and beats its rivals. If protocol 
insecurity is the only consideration, I am willing to help by implementing FTPS 
(FTP over TLS) support and sending a patch, if that would change Mozilla's 
decision to keep this functionality. Please let me know if I can do anything, 
because I won't try to implement FTPS support if it won't be merged.

Also, Google still index FTPs. I find it strange if the user clicks on Google 
search result and it could not be opened in a browser.



On 19.03.2020 03:24, Michal Novotny wrote:
> We plan to remove FTP protocol implementation from our code. This work is 
> tracked in bug 1574475 [1]. The plan is to
>
> - place FTP behind a pref and turn it off by default on 77 [2]
> - keep FTP enabled by default on 78 ESR [3]
> - remove the code completely at the beginning of 2021
>
> We're doing this for security reasons. FTP is an insecure protocol and there 
> are no reasons to prefer it over HTTPS for downloading resources. Also, a 
> part of the FTP code is very old, unsafe and hard to maintain and we found a 
> lot of security bugs in it in the past. After disabling FTP in our code, the 
> protocol will be handled by external application, so people can still use it 
> to download resources if they really want to. However, it won't be possible 
> to view and browse directory listings.
>
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1574475
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1622409
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1622410
>


signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: FTP protocol implementation

[Nhi Nguyen]

Update: In light of recent events, we will only disable FTP in Nightly,
starting from 77. FTP will remain enabled in release until further notice.

On Thu, Mar 19, 2020 at 7:01 AM Michal Novotny 
wrote:

> We added the telemetry probes in bug 1579507 [1] to see how many users
> still use FTP. The usage was pretty low as you can see in bug 1570155 [2].
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1579507
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1570155#c5
>
>
> On 3/19/20 10:26 AM, Johann Hofmann wrote:
> > Can you share some insight into the usage telemetry that was considered
> > for unshipping this?
> >
> > On Thu, Mar 19, 2020 at 9:02 AM Henri Sivonen  > > wrote:
> >
> > On Thu, Mar 19, 2020 at 2:24 AM Michal Novotny
> > mailto:michal.novo...@gmail.com>> wrote:
> >  > We plan to remove FTP protocol implementation from our code.
> >
> > Chrome's status dashboard says "deprecated" and
> > https://textslashplain.com/2019/11/04/bye-ftp-support-is-going-away/
> > said the plan was to turn FTP off by default in version 80. Yet, I
> > just successfully loaded ftp://ftp.funet.fi in Chrome 80 on Mac and
> in
> > Edge 82 (Canary) on Windows 10, and I'm certain I haven't touched the
> > flag in either. (The location bar kept showing the ftp:// URL, so it
> > doesn't appear to be a case of automatically trying HTTP.)
> >
> > Do we know why Chrome didn't proceed as planned? Do we know what
> their
> > current plan is?
> >
> > Do we know if Edge intends to track Chrome on this feature or to make
> > an effort to patch a different outcome?
> >
> > --
> > Henri Sivonen
> > hsivo...@mozilla.com 
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org  dev-platform@lists.mozilla.org>
> > https://lists.mozilla.org/listinfo/dev-platform
> >
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: -less RDM

[Micah Tigley]

Hi all,

Later this week, we’ll be enabling a new version of the Responsive Design
Mode tool that no longer relies on  as part of the
initiative to make DevTools Fission-compatible. For now, the pref will only
be enabled in Firefox Nightly as we work with QA to ensure the stability of
the tool.

This new version of RDM will be embedded inside the browser UI (rather than
live in a tab like today) and website content will be rendered inside the
 element just like normal. Users should not expect any
significant difference between this version and the current one.

Pref: devtools.responsive.browserUI.enabled

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1621306

Tracking bug for RDM Fission:
https://bugzilla.mozilla.org/show_bug.cgi?id=1574885. We ask anyone finding
anything wrong with the new tool once the pref is on to report bugs
blocking this meta.

- Micah
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: Delegated Credentials for TLS 1.3

[Kevin Jacobs]

*Summary*: Last year, we announced

intent to implement Delegated Credentials for TLS 1.3. This extension
allows server operators to delegate the authority of an end-entity
certificate to a short-lived “sub-certificate”, which uses a separate
keypair and inherits both scope and limitations from the issuing
certificate. This enables more frequent key rotation and stronger
protections on the end-entity private key. It also streamlines the process
for experimenting with, and incorporating new signing algorithms into TLS.

Since the original announcement, we’ve landed the implementation and run a
breakage study in Nightly with positive results. We now intend to enable
this feature for pre-release channels, starting in Nightly 78. As the
specification is still in late draft, this will apply only to Nightly for
the time being, and we will follow-up to this thread before enabling it in
Beta. Once RFC status is reached, our intention is to let the feature ride
the trains to release, and again we will update this thread.

Further details on the Delegated Credentials extension can be found in the
specification linked below.

*Bug*: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1624378

*Link to standard*: https://tools.ietf.org/html/draft-ietf-tls-subcerts-07

*Platform coverage*: All platforms

*Estimated target release*: To Be Determined

*Preference behind which this will be implemented*: This is controlled via
the security.tls.enable_delegated_credentials pref.

Thanks,

Kevin
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform