Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Dão Gottwald]

Are we going to remove support for this pref in a subsequent release?

Am Mo., 12. Aug. 2019 um 10:05 Uhr schrieb Johann Hofmann <
jhofm...@mozilla.com>:

> In desktop Firefox 70, we intend to remove Extended Validation (EV)
> indicators from the identity block (the left hand side of the URL bar which
> is used to display security / privacy information). We will add additional
> EV information to the identity panel instead, effectively reducing the
> exposure of EV information to users while keeping it easily accessible.
>
> Before:
>
>
> After:
>
>
> The effectiveness of EV has been called into question numerous times over
> the last few years, there are serious doubts whether users notice the
> absence of positive security indicators and proof of concepts have been 
> pitting
> EV against domains  for
> phishing.
>
> More recently, it has been shown  that EV
> certificates with colliding entity names can be generated by choosing a
> different jurisdiction. 18 months have passed since then and no changes
> that address this problem have been identified.
>
> The Chrome team recently removed EV indicators from the URL bar in Canary
> and announced their intent to ship this change in Chrome 77
> .
> Safari is also no longer showing the EV entity name instead of the domain
> name in their URL bar, distinguishing EV only by the green color. Edge is
> also no longer showing the EV entity name in their URL bar.
>
>
>
> On our side a pref for this
> (security.identityblock.show_extended_validation) was added in bug 1572389
>  (thanks :evilpie
> for working on it!). We're planning to flip this pref to false in bug
> 1572936 .
>
> Please let us know if you have any questions or concerns,
>
> Wayne & Johann
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Disabling the UINEEDED keyword

[Dão Gottwald]

Again, can we please re-enable the uiwanted keyword so I can continue to
use it until the replacement is implemented? The suggested interim
replacement, needinfo, does not fit.

It doesn't seem that there's much won by overeagerly disabling the keyword
as the queue (that nobody has been looking at so far, so it isn't really a
queue) is already long anyway, and the lack of the keyword hinders my
ability to triage bugs efficiently.

Thanks,
Dao

Am Mi., 15. Mai 2019 um 19:09 Uhr schrieb Emma Humphries :

> Hi Dão,
>
> Thank you for calling out that use case. This week I met with one of the
> UX managers to plan a replacement for the keyword. The goal here is to have
> a work queue that UX can triage and is visible to all the stakeholders.
>
> I'll report on that soon.
>
> -- Emma
>
> On Wed, May 15, 2019 at 3:41 AM Dão Gottwald 
> wrote:
>
>> After reading the bug, it seems that this use case was just completely
>> missed, and only UX people who barely use bugzilla were consulted.
>> Therefore I'd like to ask that we re-enable this keyword until we have a
>> proper replacement.
>>
>> Thanks,
>> Dao
>>
>> Am Mi., 15. Mai 2019 um 12:28 Uhr schrieb Dão Gottwald <
>> dgottw...@mozilla.com>:
>>
>>> I used the uiwanted keyword in Firefox front-end components to indicate
>>> that a bug needs UX input before it can move forward, without explicitly
>>> flagging a particular UX person because the bug has a low priority. It's
>>> valuable meta data even if nobody monitors all uiwanted bugs. How do you
>>> suggest we support that use case going forward? There's the whiteboard but
>>> that seems like a step backwards.
>>>
>>> TIA, Dao
>>>
>>> Am Fr., 26. Apr. 2019 um 01:52 Uhr schrieb Emma Humphries <
>>> e...@mozilla.com>:
>>>
>>>> Typo: s/uineeded/uiwanted/gi
>>>>
>>>> On Thu, Apr 25, 2019 at 4:50 PM Emma Humphries 
>>>> wrote:
>>>>
>>>>> Previously teams and other contributors have used the uineeded keyword
>>>>> in Bugzilla to indicate if the UX team’s expertise was needed.
>>>>>
>>>>> However, that keyword, with a couple of exceptions, is not currently
>>>>> monitored by that team.
>>>>>
>>>>> In order to prevent misunderstandings, I will be disabling the
>>>>> uineeded keyword in Bugzilla. It will appear in bugs that have it
>>>>> until it is removed so you may clean up backlogs, but it will no longer be
>>>>> able to be set for new bugs.
>>>>>
>>>>> If you are working with a UX team member who is monitoring Bugzilla
>>>>> bugs (DevTools and Activity Stream) then please use needinfo to call out
>>>>> bugs to them.
>>>>>
>>>>> Otherwise, please work with the UX managers (Tif, Markus, and Anthony
>>>>> who all reviewed this) to ask about getting UX resources to help with
>>>>> your project.
>>>>>
>>>>> The relevant BMO bug for this is:
>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1541690
>>>>>
>>>>> In May I will be working with the UX managers to investigate a
>>>>> replacement UX triage for Bugzilla.
>>>>>
>>>>> -- Emma
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Disabling the UINEEDED keyword

[Dão Gottwald]

After reading the bug, it seems that this use case was just completely
missed, and only UX people who barely use bugzilla were consulted.
Therefore I'd like to ask that we re-enable this keyword until we have a
proper replacement.

Thanks,
Dao

Am Mi., 15. Mai 2019 um 12:28 Uhr schrieb Dão Gottwald <
dgottw...@mozilla.com>:

> I used the uiwanted keyword in Firefox front-end components to indicate
> that a bug needs UX input before it can move forward, without explicitly
> flagging a particular UX person because the bug has a low priority. It's
> valuable meta data even if nobody monitors all uiwanted bugs. How do you
> suggest we support that use case going forward? There's the whiteboard but
> that seems like a step backwards.
>
> TIA, Dao
>
> Am Fr., 26. Apr. 2019 um 01:52 Uhr schrieb Emma Humphries <
> e...@mozilla.com>:
>
>> Typo: s/uineeded/uiwanted/gi
>>
>> On Thu, Apr 25, 2019 at 4:50 PM Emma Humphries  wrote:
>>
>>> Previously teams and other contributors have used the uineeded keyword
>>> in Bugzilla to indicate if the UX team’s expertise was needed.
>>>
>>> However, that keyword, with a couple of exceptions, is not currently
>>> monitored by that team.
>>>
>>> In order to prevent misunderstandings, I will be disabling the uineeded
>>> keyword in Bugzilla. It will appear in bugs that have it until it is
>>> removed so you may clean up backlogs, but it will no longer be able to be
>>> set for new bugs.
>>>
>>> If you are working with a UX team member who is monitoring Bugzilla bugs
>>> (DevTools and Activity Stream) then please use needinfo to call out bugs to
>>> them.
>>>
>>> Otherwise, please work with the UX managers (Tif, Markus, and Anthony
>>> who all reviewed this) to ask about getting UX resources to help with
>>> your project.
>>>
>>> The relevant BMO bug for this is:
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1541690
>>>
>>> In May I will be working with the UX managers to investigate a
>>> replacement UX triage for Bugzilla.
>>>
>>> -- Emma
>>>
>>>
>>>
>>>
>>>
>>>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Disabling the UINEEDED keyword

[Dão Gottwald]

I used the uiwanted keyword in Firefox front-end components to indicate
that a bug needs UX input before it can move forward, without explicitly
flagging a particular UX person because the bug has a low priority. It's
valuable meta data even if nobody monitors all uiwanted bugs. How do you
suggest we support that use case going forward? There's the whiteboard but
that seems like a step backwards.

TIA, Dao

Am Fr., 26. Apr. 2019 um 01:52 Uhr schrieb Emma Humphries :

> Typo: s/uineeded/uiwanted/gi
>
> On Thu, Apr 25, 2019 at 4:50 PM Emma Humphries  wrote:
>
>> Previously teams and other contributors have used the uineeded keyword in
>> Bugzilla to indicate if the UX team’s expertise was needed.
>>
>> However, that keyword, with a couple of exceptions, is not currently
>> monitored by that team.
>>
>> In order to prevent misunderstandings, I will be disabling the uineeded
>> keyword in Bugzilla. It will appear in bugs that have it until it is
>> removed so you may clean up backlogs, but it will no longer be able to be
>> set for new bugs.
>>
>> If you are working with a UX team member who is monitoring Bugzilla bugs
>> (DevTools and Activity Stream) then please use needinfo to call out bugs to
>> them.
>>
>> Otherwise, please work with the UX managers (Tif, Markus, and Anthony
>> who all reviewed this) to ask about getting UX resources to help with
>> your project.
>>
>> The relevant BMO bug for this is:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1541690
>>
>> In May I will be working with the UX managers to investigate a
>> replacement UX triage for Bugzilla.
>>
>> -- Emma
>>
>>
>>
>>
>>
>>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Plan for Sunsetting MozReview

[Dão Gottwald]

This may have been discussed before since it's kind of an obvious question:

Was there a conscious decision not to post phabricator review comments to
bugzilla? It's a somewhat significant change from how we've used bugzilla.
I can see a potential upside of separating review comments from other
planning and chatter. Then again, the line isn't always drawn easily. Plus,
it makes it harder to migrate away from phabricator should we want that at
some unknown point; that MozReview posted comments to bugzilla turns out to
be quite valuable now.

I'd prefer if review comments stayed in bugzilla with an option to hide
them.

dao



2018-07-26 20:37 GMT+02:00 Mark Côté :

> To follow up on some previous threads, here is the plan for deprecating,
> archiving, and decommissioning MozReview.
>
> The MozReview shutdown deadline is approaching. Although enhanced
> commit-series support is still in progress (see update below), MozReview
> users should start familiarizing themselves with Phabricator now. We have a
> guide specifically for MozReview users to ease the transition (which will
> be updated when the commit-series work is finalized): https://moz-conduit.
> readthedocs.io/en/latest/mozreview-migration-guide.html
>
> From August 6 to August 20, use of MozReview will be restricted to updates
> to existing reviews. In other words, review cycles in progress will be
> given until August 20 to be completed, but no new commit series will be
> permitted.
>
> On August 20, we will remove public access to MozReview and archive
> patches. Every landed, in-progress, and abandoned patch will be downloaded
> from MozReview and stored in an S3 bucket. The “stub attachments” in
> Bugzilla that currently redirect to MozReview will be updated to link to
> the appropriate S3 bucket. Review flags and bug comments will be preserved.
>
> After archiving is complete and verified, the MozReview servers will be
> decommissioned.
>
> We will also be writing a simple redirection service to map specific
> MozReview reviews to associated BMO comments, review requests to associated
> bugs, and review-request diffs to the appropriate S3 buckets. This service
> will be up shortly after MozReview is decommissioned.
>
> We realize and apologize that this is a fairly short timeline; however,
> the current location of the MozReview servers is in the process of being
> shut down, and thus it is urgent that we decommission this service soon to
> allow an orderly exit.
>
> As for enhanced support for series of commits in Phabricator, the new
> command-line interface to submit, update, and apply series (bug 1471678) is
> currently in review. The first release will support Mercurial only, but
> git-cinnabar support will follow shortly (the code is designed with it in
> mind). Work on series support in Lando (bug 1457525) is progressing; we
> will be posting screenshots of the new UI shortly. It should be ready in
> 2-3 weeks.
>
> Please note that we eventually plan to decommission Splinter as well;
> however, we know we need some time to work out the kinks in Phabricator.
> Splinter will remain operational near-term, but we ask everybody to
> familiarize themselves with Phabricator and file bugs when things don't
> work. *Please do not wait for Splinter EOL to try Phabricator; we need your
> feedback before then in order to act on it.*
>
> Mark
>
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Update: Phabricator and commit series

[Dão Gottwald]

2018-07-03 21:34 GMT+02:00 Mark Côté :

> We’re aiming for late July for these implementations, which will allow us
> to close down MozReview soon after, in time for the data center closure.
>


What's going to happen to bugzilla attachments pointing to MozReview? Are
we going to migrate the patches somewhere? It probably doesn't matter too
much for patches that landed, since the review comments and the final patch
are still there. However, there are bugs with work-in-progress patches
stashed away in MozReview.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to move Activity Stream into its own process

[Dão Gottwald]

This is about the code behind about:newtab and about:home, yes? Or some
broader Activity Stream magic? Activity Stream has become kind of a fuzzy
term, to the point where I'm not sure anymore what it means.

2018-06-18 21:58 GMT+02:00 Kris Maglione :

> +1
>
> This should also have some memory benefits by preventing us from
> unnecessarily loading AS things into multiple content processes, like we do
> now.
>
>
> On Mon, Jun 18, 2018 at 03:35:01PM -0400, Mike Conley wrote:
>
>> (posted on both dev-platform and firefox-dev. Please send replies to
>> dev-platform)
>>
>> Hello all,
>>
>> Just sending a quick note to let you know that I've filed bug 1469072[1]
>> to
>> move Activity Stream into its own content process.
>>
>> This is something that Fission needs, but we're hoping to squeeze some
>> performance benefits out of it as well by reducing, reusing and recycling
>> various Activity Stream things since they'll all be contained within a
>> single process. It might also allow us to cache more Activity Stream
>> scripts in ScriptPreloader[2], since we can reasonably assume only trusted
>> JavaScript will be running within the Activity Stream content process.
>>
>> This work is going to be handled by my intern, Jay Lim. If you have any
>> concerns with this plan, please bring them to my attention - commenting in
>> the bug, emailing me, or responding to this thread on dev-platform is
>> fine.
>>
>> Thanks!
>>
>> -Mike
>>
>> [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1469072
>> [2]: I wrote about ScriptPreloader on my blog here:
>> https://mikeconley.ca/blog/2018/05/30/firefox-performance-update-9/
>>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: MXR permanently offline, please transition to DXR

[Dão Gottwald]

Can we please automatically redirect from
https://mxr.mozilla.org/mozilla-central/source/x/y.z to
https://dxr.mozilla.org/mozilla-central/source/x/y.z? My browsing history
is littered with mxr URLs which used to make it very easy to find a file by
typing part of the name. As it stands all those URLs are broken.

2016-06-22 20:30 GMT+02:00 Lawrence Mandel :

> Mozilla Cross-Reference, better known as MXR (https://mxr.mozilla.org),
> was taken offline on June 13, 2016, to investigate a potential security
> issue. After careful review of the codebase, we have decided to accelerate
> the planned transition from MXR to its more modern equivalent, DXR (
> https://dxr.mozilla.org), instead of bringing MXR back online. As far as
> we know there was never a security compromise, but the unsupported legacy
> codebase (forked from an old version of LXR) would require significant time
> and effort to rewrite and bring up to spec.
>
> Our transition plan is as follows:
>
>
>-
>
>Add an interstitial web page at https://mxr.mozilla.org that displays
>a best-guess URL for the equivalent https://dxr.mozilla.org file data.
>This will help interactive users retrieve data from historical links in
>applications like Bugzilla.
>-
>
>Redirect certdata.txt and effective_tld_names.dat to their canonical
>source code repositories instead of DXR. All other search queries and
>automatic pulling of raw files by third parties will no longer be supported
>at the https://mxr.mozilla.org URL.
>-
>
>Index the remaining repos listed in MXR in DXR for data parity, using
>bug 1281443 to track progress. Repos will be indexed in the order listed
>unless otherwise specified. If you need to prioritize the indexing of
>specific repos, please open a bug and block against bug 1281443.
>
>
> Our expectation is that the interstitial page will be in place and the
> following remaining high-priority repos will be indexed by June 24th, 2016:
>
>-
>
>add-ons
>-
>
>servo
>-
>
>l10n
>
>
> If you have concerns, questions, or requests, please open a new bug and
> mark it as blocking bug 1281443 or add a comment to one of its existing
> dependent bugs. Additional status updates will also be posted to bug
> 1281443 and its dependent bugs.
>
> Lawrence
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform