What about using it to help detect phishing sites.
For example, when filling out a user/password form, if the touch bar
displayed the domain name (not the full URL) we're submitting to (for
example mybank.com), that might help prevent some phishing attacks. The
user just has to glance down at the
Which, from my perspective, is justification to disable reading the sensor
until it can be implemented in a way that prevents the cross-origin
stealing attack. Users shouldn't have to worry about this.
Haik
On Wed, Apr 26, 2017 at 8:28 AM, Ehsan Akhgari
wrote:
> On 04/25/2017 08:26 PM, Salvador
On Fri, Jul 21, 2017 at 7:48 AM, Andrea Marchesini
wrote:
> There are some APIs able to read files in the content process using
> nsFileInputStream: FileReader is one of them.
> The file is opened on the parent process (because of a FilePicker, or
> Entries API), the file descriptor is sent to th
On Mon, Feb 12, 2018 at 6:30 AM, Eric Rescorla wrote:
> On Mon, Feb 12, 2018 at 6:09 AM, Boris Zbarsky wrote:
> Instead, maybe we can arrange for Phab/Lando to put the bug #in the short
> message, potentially also with r=
>
I agree. Having the bug ID on the first line of the commit message is
We intend to ship a process-level sandbox for the NPAPI Flash plugin on
macOS in 61. This will provide a degree of process isolation at the expense
of some lesser-used Flash functionality[1]. You can enable the sandbox now
on Nightly, globally for all sites, by setting
dom.ipc.plugins.sandbox-level
On Tue, Mar 20, 2018 at 10:54 AM, Haik Aftandilian wrote:
> We intend to ship a process-level sandbox for the NPAPI Flash plugin on
> macOS in 61. This will provide a degree of process isolation at the expense
> of some lesser-used Flash functionality[1]. You can enable the sandbox
On Sun, May 13, 2018 at 8:00 AM, Jean-Yves Avenard
wrote:
> Hi
> On 12/05/2018 04:47, Boris Zbarsky wrote:
>
>> Just to be clear, when doing a bisect, one _can_ just deal with local
>> builds. But the point is that then it takes tens of minutes per build as
>> you point out. So a bisect task th
On Tue, Feb 9, 2016 at 2:47 AM, Marco Bonardo wrote:
> Based on that, bumping the timeout may have 2 downsides, long term:
> - slower tests for everyone
> - sooner or later 90 seconds won't be enough again. Are we going to bump to
> 180 then?
>
Essentially restating Marco's concern, increasing t
On Thu, Apr 14, 2016 at 1:54 AM, Chris Peterson
wrote:
> Summary: Treat cookies set over non-secure HTTP as session cookies
>
> Exactly one year ago today (!), Henri Sivonen proposed [1] treating
> cookies without the `secure` flag as session cookies.
>
> PROS:
>
> * Security: login cookies set o
On Fri, Apr 15, 2016 at 7:37 PM, Chris Peterson
wrote:
> On 4/15/16 7:47 AM, Tantek Çelik wrote:
>
>> What steps can we take in this direction WITHOUT breaking web compat?
>>
>
> Would this feature actually break web compatibility? Or just needlessly
> annoy users?
>
> In his original post, Henri
The fix for bug 1272772 [1] makes some minor changes to the OS X content
sandbox which is only enabled on Nightly. More changes will come as we
whittle down and simplify the sandbox rules. If you think you are hitting a
regression due to sandboxing on OS X, it's a good idea to check the OS X
Consol
Since the integration of bug 1299329
[1]
in Nightly, these error messages are printed to the terminal and
system.log so you'll see them when running Firefox from the command line on
Mac.
They are not known to cause any browser issues so you can ignore them.
These are due to sandbox restriction
If you don't build on macOS, read no further.
With the latest XCode (10.0) just released, mozilla-central fails to build
due to bug 1492210 "nsCocoaUtils.mm compile error on macOS 10.13 with 10.14
SDK" [1]. I recommend avoiding installing the new XCode until we have this
fixed. If you've configure
This has been resolved. The fix for bug 1492210 is now in mozilla-central,
thanks to Miko.
Haik
On Tue, Sep 18, 2018 at 11:30 AM Haik Aftandilian
wrote:
> If you don't build on macOS, read no further.
>
> With the latest XCode (10.0) just released, mozilla-central fails to buil
With the fix for bug 1494326[1] (on autoland), when run on macOS, "mach
run" has a new option "--macos-open" to launch the browser using the
open(1) command. Note --macos-open and --debug are mutually exclusive and
mach will exit with an error if both options are used.
Per the open(1) man page, "t
Please take a look if you debug Firefox on macOS.
Apple's notary service[1] is a new way to sign macOS applications that has
some security benefits[2] and provides a slight user experience
improvement[3] when users download the application and run it for the first
time. Specifically, the dialog us
s only
> been a handful of times that I had to debug an official build. Having to
> disable SIP to debug isn't ideal, but tolerable given how infrequently
> this would be necessary. I'd be interested to hear if others have had to
> debug official builds more frequently.
>
>
On Thu, Apr 11, 2019 at 7:45 AM Boris Zbarsky wrote:
> On 4/11/19 3:07 AM, Haik Aftandilian wrote:
> > With notarization, Nightly channel builds will not be debuggable unless
> the
> > system is booted with system integrity protection (SIP)[1] disabled.
>
> Do you k
Release Engineering will soon be turning on Apple Notarization and Hardened
Runtime[1] for Nightly channel builds. See previous discussion[2] on
dev-platform for more information.
First, I want to recognize that this required a very significant amount of
work from the Release Engineering team to a
if you have any questions.
Thanks,
Haik
On Wed, Jun 26, 2019 at 1:27 PM Haik Aftandilian
wrote:
> Release Engineering will soon be turning on Apple Notarization and
> Hardened Runtime[1] for Nightly channel builds. See previous discussion[2]
> on dev-platform for more information.
>
&
20 matches
Mail list logo
