Re: Proposed W3C Charter: Verifiable Claims Working Group
On Mon, Dec 12, 2016 at 6:37 PM, Martin Thomson wrote: > On Tue, Dec 13, 2016 at 5:56 AM, Eric Rescorla wrote: > > Following up to myself: if the plan is really that people will have a > > single identity that they then present to everyone and that claims hang > > off, I think W3C should not standardize that. > > A lot hinges on the nature of that identifier, but couldn't it be a > pseudonymous identifier, even unique to the specific transaction? > That's not enough, because what you need is blind signatures over the claims. Otherwise, the issuer can tell who you are authenticating to. It seems pretty clear that the inspector gets the identifier (see fig 5 here https://w3c.github.io/webpayments-ig/VCTF/architecture/) and so I don't see how this isn't linkable Building a set of issuers that sites are willing to trust creates a > whole new set of problems. Say that I accept claims from the > California DMV for the purposes of age. When you produce a document > signed by the DMV saying that you are 21, I also learn that (with high > probability) you live in California. > > If which entities are trusted, that has another set of consequences. > What consequences on whether the relying party does or is able to > advertise which entities it trusts. > > All of this stuff matters at the scale of the web. > Yes, all this too -Ekr ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Verifiable Claims Working Group
On Tue, Dec 13, 2016 at 5:56 AM, Eric Rescorla wrote: > Following up to myself: if the plan is really that people will have a > single identity that they then present to everyone and that claims hang > off, I think W3C should not standardize that. A lot hinges on the nature of that identifier, but couldn't it be a pseudonymous identifier, even unique to the specific transaction? Building a set of issuers that sites are willing to trust creates a whole new set of problems. Say that I accept claims from the California DMV for the purposes of age. When you produce a document signed by the DMV saying that you are 21, I also learn that (with high probability) you live in California. If which entities are trusted, that has another set of consequences. What consequences on whether the relying party does or is able to advertise which entities it trusts. All of this stuff matters at the scale of the web. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Windows CPU power settings
I've been assessing new hardware options for Mozilla to issue to developers. As part of evaluating some dual socket Xeon processors, I found some unexpected behavior: these processors routinely underclock in Windows 10 unless several cores or are used. Contrast with the behavior of my i7 Skylake processor, which seems to ramp up to full clock pretty rapidly, even when only a single core is used. The Windows 10 power settings appear to set the minimum CPU frequency at 5% or 10% of maximum. When I cranked this up to 100%, artifact build time dropped from ~170s to ~77s and full build configure dropped from ~165s to ~97s! If you are a Windows user with Xeons in your desktop, you may want to visit Control Panel -> Hardware and Sound -> Power Options -> Edit Plan Settings -> Change advanced power settings -> Process power management -> Minimum processor state and crank that up and see what happens. Note: running your CPU at 100% all the time may impact your power bill! Bug 1323106 has been opened to track improving the ability of the build system (namely `mach doctor`) to improve matters. If you would like to report success/failure of changing power settings or if you know a thing or two about CPU power management and can provide technical assistance, please weigh in there. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: MediaError::message attribute
On 12/12/16 4:26 PM, Jean-Yves Avenard wrote: As of December 13th 2016, I intend to turn MediaError::message attribute on by default on all platforms. It has been developed behind the dom.MediaError.message.enabled preference. Looks good to me. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: MediaError::message attribute
Hi As of December 13th 2016, I intend to turn MediaError::message attribute on by default on all platforms. It has been developed behind the dom.MediaError.message.enabled preference. Other UAs shipping this or intending to ship it are chrome and edge (that I know of). This feature was first introduced in bug 1299072 (Firefox 51) as a way to help developers identify why they got decoding failures. Since Chrome caught on and created https://github.com/whatwg/html/issues/2085.. Changes have been accepted and is pending a WPT test. Regards Jean-Yve smime.p7s Description: S/MIME Cryptographic Signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to remove: support for installing multiple xpis simultaneously
In case anyone is wondering if removing the "multi xpi" feature is going to affect hybrid addons which are embedding a webextension, the answer is: no, not at all, they are completely separate and unrelated features. Best, Luca ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Verifiable Claims Working Group
Following up to myself: if the plan is really that people will have a single identity that they then present to everyone and that claims hang off, I think W3C should not standardize that. -Ekr On Mon, Dec 12, 2016 at 8:48 AM, Eric Rescorla wrote: > I took a quick look at this material and it's very hard to tell what the > actual privacy properties are: > > "From a privacy perspective it is important that information that is > intended to remain private is handled appropriately. Maintaining the trust > of a verifiable claims ecosystem is important. Verifiable claims technology > defined by this group should not disclose private details of the > participants' identity or other sensitive information unless required for > operational purposes, by legal or jurisdictional rules, or when > deliberately consented to (e.g. as part of a request for information) by > the holder of the information. The design of any data model and syntax(es) > should guard against the unwanted leakage of such data." > > But then when I read their architecture, I see: > "In order for Jane (Holder and Subject) to have information assigned to > her, she must get an identifier (Subject Identifier)." > > Which makes it sound like this is going to leak a huge amount of tracking > information (effectively being an identity credential with attributes > attached). There has been a huge amount of work on using crypto to allow > you to prove specific claims without information leakage (cf. > https://www.microsoft.com/en-us/research/project/u-prove/), but this > doesn't seem to reflect any of it, rather opting for a much more naive > design which is going to have much worse privacy properties. Is that really > the intent here? > > -Ekr > > > > On Fri, Dec 9, 2016 at 6:17 PM, L. David Baron wrote: > >> The W3C is proposing a new charter for: >> >> Verifiable Claims Working Group >> https://www.w3.org/2017/vc/charter >> https://lists.w3.org/Archives/Public/public-new-work/2016Dec/0003.html >> >> Mozilla has the opportunity to send comments or objections through >> Sunday, January 15, 2017. >> >> 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 >> >> > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Verifiable Claims Working Group
I took a quick look at this material and it's very hard to tell what the actual privacy properties are: "From a privacy perspective it is important that information that is intended to remain private is handled appropriately. Maintaining the trust of a verifiable claims ecosystem is important. Verifiable claims technology defined by this group should not disclose private details of the participants' identity or other sensitive information unless required for operational purposes, by legal or jurisdictional rules, or when deliberately consented to (e.g. as part of a request for information) by the holder of the information. The design of any data model and syntax(es) should guard against the unwanted leakage of such data." But then when I read their architecture, I see: "In order for Jane (Holder and Subject) to have information assigned to her, she must get an identifier (Subject Identifier)." Which makes it sound like this is going to leak a huge amount of tracking information (effectively being an identity credential with attributes attached). There has been a huge amount of work on using crypto to allow you to prove specific claims without information leakage (cf. https://www.microsoft.com/en-us/research/project/u-prove/), but this doesn't seem to reflect any of it, rather opting for a much more naive design which is going to have much worse privacy properties. Is that really the intent here? -Ekr On Fri, Dec 9, 2016 at 6:17 PM, L. David Baron wrote: > The W3C is proposing a new charter for: > > Verifiable Claims Working Group > https://www.w3.org/2017/vc/charter > https://lists.w3.org/Archives/Public/public-new-work/2016Dec/0003.html > > Mozilla has the opportunity to send comments or objections through > Sunday, January 15, 2017. > > 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 > > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to remove: support for installing multiple xpis simultaneously
tl;dr: We have two existing features (multipackage xpis and the InstallTrigger api capability for installing multiple xpis in a single call) that are not widely used. I would like to remove them to reduce complexity in the add-ons manager. Background: The XPI file format is used for several types of add-ons including extensions (both webextensions and the older xul and bootstrap ones), themes, and language packs. One of the more obscure features of the format is "multi-package" xpis which are pretty much what you might guess from the name: a collection of other xpis all bundled into a single file. And then we have the InstallTrigger api, which provides a way to install xpis from content (guarded by permissions prompts of course). This is the api that is is invoked when you press the "Add to Firefox" button on an addons.mozilla.org page but it is also documented for use by others. This api is an ancient one that we inherited from Netscape (!!) though it has never been standardized or implemented in other browsers. Among other things, InstallTrigger provides a way to install multiple xpis with a single api call. Unfortunately we don't have any telemetry available about how frequently these two features are used but empirically they appear to be very uncommon. However, they are responsible for a good deal of complexity in the add-ons manager and, more urgently, they complicate the UX design for current efforts to display detailed permissions prompts to users when they install a webextension. Rather than deal with the UX design and corresponding implementation complexity of install operations that include multiple webextensions that need to be individually approved by the user, I'm proposing that we drop support for multi-package xpis and restrict the InstallTrigger api to only allow installing a single xpi at a time. I would like to do this in Firefox 53. -Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Presentation API on Fennec
On 12/12/16 4:57 AM, Mounir Lamouri wrote: What specifically do you have in mind when you say that 1-UA mode might lack features? The use of APIs on the other device that you mention. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Presentation API on Fennec
On Mon, 12 Dec 2016, at 04:00, Boris Zbarsky wrote: > On 12/11/16 8:47 AM, Mounir Lamouri wrote: > > On Sat, 10 Dec 2016, at 17:58, Boris Zbarsky wrote: > >> OK, but a website doing this won't work in Chrome Android. So what > >> would websites actually do in practice? > > > > Not sure what you mean wouldn't work. If a website is a good web citizen > > and uses PresentationRequest with an array of URLs such as > > ['http://example.com', 'cast://example', 'dial://example', > > 'mozapp://example' ], Chrome Android will work fine because it will use > > the "cast://" URL. > > I may just be missing something or misunderstanding how the API works... > > Is the 1-UA vs 2-UAs mode thing transparent to the page? Based on the > descriptions of the modes it sounded to me like you can do things in at > least 2-UAs mode that you can't do in 1-UA mode; not sure about vice > versa. So presumably it's not entirely transparent? Or is the idea > that anything that works in 1-UA mode is available in 2-UAs mode and the > APIs are identical for that subset of functionality, so a page that > pretends like it's always working with 1-UA mode will just work with > 2-UAs mode? What specifically do you have in mind when you say that 1-UA mode might lack features? Technically, 1-UA mode is when a page is rendered on the client and sent to the remote device. It's mostly a technical detail because one can't render HTML pages on a Chrome Cast without creating an application, Chrome folks call pure HTML rendering 1-UA mode. It is fairly similar to tab mirroring. I don't think any feature should be lacking except maybe access to the APIs on the other device. -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
