Re: TIFU by using Math.random()

[Boris Zbarsky]

On 11/25/15 9:59 AM, Mike Hoye wrote:

Doing the wrong thing really fast is not hard.


You have now discovered the key optimization secret of web browsers.

-Boris

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

Re: Using browser stored credentials for http://mywebsi.de also on https://mywebsi.de

[Thomas Schäfer]

> > After testing this, we realized that many of our customers stored their 
> > credential in the browser and by switching from non-ssl to ssl, they lost 
> > the possibility to use them also on the ssl-version of the portal page.
> 
> Are these stored as cookies?  Something else?
> 
> -Boris

No, the are stored using the mechanism firefox offers for storing credentials 
(Settings -> Security).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Using browser stored credentials for http://mywebsi.de also on https://mywebsi.de

[Thomas Schäfer]

Hi,

I am working for a webside which currently offers a portal page with ssl and 
non-ssl version having a login form posting to a ssl-only login server and 
providing the authenticated content ssl-only. Still most of our users use the 
non-ssl version of that page.

In order to increase to level of security offered for our users, we are 
thinking on switching the portal page to ssl-only using a redirect in the first 
place (yes, hsts might follow).

After testing this, we realized that many of our customers stored their 
credential in the browser and by switching from non-ssl to ssl, they lost the 
possibility to use them also on the ssl-version of the portal page. It looks 
like Mozilla Firefox being the only browser to behave like this and not using 
the credentials stored for a domain when using the non-ssl version also for the 
ssl version. This leads to many support issues helping the customers either to 
reveal their password for themselves by directing them to the settings or 
helping them to reset and change their passwords.

As blaming login forms on non-ssl pages even more starting with Firefox version 
44, more provider of pages like us will probably change the behaviour, but will 
find their users in that trap of not being helped by the browser. This even 
might prevent provider with non-ssl login pages to switch being afraid of the 
support volumnes they are expected to handle.

Are there any chances to help the user using the stored credentials on the 
serverside?

Would be happy to get some help on that issue from the community.

Best regards,
Thomas Schäfer
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using browser stored credentials for http://mywebsi.de also on https://mywebsi.de

[Boris Zbarsky]

On 11/25/15 12:24 PM, Thomas Schäfer wrote:

No, the are stored using the mechanism firefox offers for storing credentials 
(Settings -> Security).


So these are HTTP Auth credentials (based on 401 responses from your 
server)?


-Boris

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

Re: Using browser stored credentials for http://mywebsi.de also on https://mywebsi.de

[Philipp Wagner]

Am 25.11.2015 um 18:33 schrieb Boris Zbarsky:
> On 11/25/15 12:24 PM, Thomas Schäfer wrote:
>> No, the are stored using the mechanism firefox offers for storing
>> credentials (Settings -> Security).
> 
> So these are HTTP Auth credentials (based on 401 responses from your
> server)?

I guess the OP is talking about passwords auto-filled into form fields?

Philipp

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

Re: Using browser stored credentials for http://mywebsi.de also on https://mywebsi.de

[Emma Humphries]

I've been reviewing Password Manager bugs the past few days, and the
https/http issue has been bugged:
https://bugzilla.mozilla.org/show_bug.cgi?id=667233 and has recent
activity. It has an owner, and a priority.

On Wed, Nov 25, 2015 at 10:06 AM, Thomas Schäfer
 wrote:
> Am Mittwoch, 25. November 2015 19:51:11 UTC+2 schrieb Philipp Wagner:
>> Am 25.11.2015 um 18:33 schrieb Boris Zbarsky:
>> > On 11/25/15 12:24 PM, Thomas Schäfer wrote:
>> >> No, the are stored using the mechanism firefox offers for storing
>> >> credentials (Settings -> Security).
>> >
>> > So these are HTTP Auth credentials (based on 401 responses from your
>> > server)?
>>
>> I guess the OP is talking about passwords auto-filled into form fields?
>>
>> Philipp
>
> Yes. Maybe I didn't made myself clear enough on that point: I am talking 
> about the auto-filled form fields where the auto-fill works on the non-ssl 
> version of the page (where they were originally saved) and does not work on 
> the ssl version of the page including the same form.
>
> Thomas
> ___
> 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: TIFU by using Math.random()

[Chris Peterson]

On 11/25/15 5:51 AM, Xidorn Quan wrote:

According to the article, SpiderMonkey's PRNG is not much better than
V8's. It seems we are using a even older algorithm, although
ironically have a better result.

After reading this article as well as some introduction from the
wikipedia, it seems to me that "xorshift+" is probably the best
algorithm to adopt, because it is simple, fast, and passes all tests
in TestU01 [1], which indicates it should also have a good quality.


We have an implementation of the xorshift128+ PRNG in 
mfbt/XorShift128PlusRNG.h from bug 1206356 that could be used.



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

Re: Using browser stored credentials for http://mywebsi.de also on https://mywebsi.de

[Thomas Schäfer]

Am Mittwoch, 25. November 2015 19:51:11 UTC+2 schrieb Philipp Wagner:
> Am 25.11.2015 um 18:33 schrieb Boris Zbarsky:
> > On 11/25/15 12:24 PM, Thomas Schäfer wrote:
> >> No, the are stored using the mechanism firefox offers for storing
> >> credentials (Settings -> Security).
> > 
> > So these are HTTP Auth credentials (based on 401 responses from your
> > server)?
> 
> I guess the OP is talking about passwords auto-filled into form fields?
> 
> Philipp

Yes. Maybe I didn't made myself clear enough on that point: I am talking about 
the auto-filled form fields where the auto-fill works on the non-ssl version of 
the page (where they were originally saved) and does not work on the ssl 
version of the page including the same form.

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

Re: Using browser stored credentials for http://mywebsi.de also on https://mywebsi.de

[Matthew N.]

Emma is correct that this is the solution for your problem and we are 
aware that it's important for the adoption of HTTPS. We already 
implemented the first half to support the upgrade of the form @action 
from HTTP to HTTPS in Firefox 41 but bug 667233 is needed to handle the 
form's origin being upgraded.


MattN

On 2015-11-25 10:11 AM, Emma Humphries wrote:

I've been reviewing Password Manager bugs the past few days, and the
https/http issue has been bugged:
https://bugzilla.mozilla.org/show_bug.cgi?id=667233 and has recent
activity. It has an owner, and a priority.

On Wed, Nov 25, 2015 at 10:06 AM, Thomas Schäfer
 wrote:

Am Mittwoch, 25. November 2015 19:51:11 UTC+2 schrieb Philipp Wagner:

Am 25.11.2015 um 18:33 schrieb Boris Zbarsky:

On 11/25/15 12:24 PM, Thomas Schäfer wrote:

No, the are stored using the mechanism firefox offers for storing
credentials (Settings -> Security).


So these are HTTP Auth credentials (based on 401 responses from your
server)?


I guess the OP is talking about passwords auto-filled into form fields?

Philipp


Yes. Maybe I didn't made myself clear enough on that point: I am talking about 
the auto-filled form fields where the auto-fill works on the non-ssl version of 
the page (where they were originally saved) and does not work on the ssl 
version of the page including the same form.

Thomas


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

Re: Dan Stillman's concerns about Extension Signing

[Chris Peterson]

On 11/25/15 11:16 AM, Jeff Gilbert wrote:

I doubt anyone is going to switch to Firefox because our extension
signing is safe. (though I do think we should have some form of
signing) But they will gladly switch away when anything breaks,
particularly when we reduce the activation energy needed to switch: If
their extension won't work in new Firefox, it doesn't matter so much
that they won't have that extension in, say, Chrome.


And that assumes the same extension, or an equivalent, is not available 
for Chrome. Picking a not-so-random example, Zotero has a Chrome extension:


https://chrome.google.com/webstore/detail/zotero-connector/ekhagklcjbdpajgpjgmbionohlpdbjgc
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Jeff Gilbert]

On Wed, Nov 25, 2015 at 3:16 AM, Till Schneidereit
 wrote:
> FWIW, I received questions about this via private email and phone calls
> from two people working on extensions that support their products. Their
> extensions sit in the review queue with not chance of getting through it
> before the signing requirement kicks in. This puts them into a situation
> where their only reasonable course of action is to advise their users to
> switch browsers.
>

Is it just me, or does this sounds completely unacceptable. Sloughing
more users? Things like this are why it's hard not to be cynical.

I doubt anyone is going to switch to Firefox because our extension
signing is safe. (though I do think we should have some form of
signing) But they will gladly switch away when anything breaks,
particularly when we reduce the activation energy needed to switch: If
their extension won't work in new Firefox, it doesn't matter so much
that they won't have that extension in, say, Chrome.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

In the new e10s multiprocess model, is that possible to calling XPCOM in the client process?

[Yonggang Luo]

I want full xpcom access in client process such
as do IMAP sync for thunderbird

So we would gain performance improvement on the thunderbird.

-- 
 此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: TIFU by using Math.random()

[Mike Hoye]

On 2015-11-25 9:33 AM, Frederik Braun wrote:

On 25.11.2015 12:42, Philip Chee wrote:



Hopefully Spidermonkey's Math.random() is better.

Phil


There have been multiple insightful responses on HN and reddit/netsec.
The short version is, that Math.random() isn't providing statistically
good randomness, because JS benchmarks use it. So it has been optimized
for performance in most browsers.
That article's key takeaway is that the word "performance" doesn't 
really mean anything absent a bunch of context-specific qualifiers, and 
you're going to get bitten if you don't understand them. Doing the wrong 
thing really fast is not hard.


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

Dan Stillman's concerns about Extension Signing

[David Rajchenbach-Teller]

I admit I have followed extension signing/scanning only very remotely,
but Dan Stillman has a number of good points:

http://danstillman.com/2015/11/23/firefox-extension-scanning-is-security-theater

Could someone who's actually involved in this feature provide an answer?

Cheers,
 David
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Mike Hommey]

On Wed, Nov 25, 2015 at 10:14:09AM +0100, David Rajchenbach-Teller wrote:
> I admit I have followed extension signing/scanning only very remotely,
> but Dan Stillman has a number of good points:
> 
> http://danstillman.com/2015/11/23/firefox-extension-scanning-is-security-theater
> 
> Could someone who's actually involved in this feature provide an answer?

As mentioned in the blog post, he posted an abridged version to
firefox-dev.

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

Re: Dan Stillman's concerns about Extension Signing

[David Rajchenbach-Teller]

And didn't receive any reply, afaict.

On 25/11/15 10:30, Mike Hommey wrote:
> On Wed, Nov 25, 2015 at 10:14:09AM +0100, David Rajchenbach-Teller wrote:
>> I admit I have followed extension signing/scanning only very remotely,
>> but Dan Stillman has a number of good points:
>>
>> http://danstillman.com/2015/11/23/firefox-extension-scanning-is-security-theater
>>
>> Could someone who's actually involved in this feature provide an answer?
> 
> As mentioned in the blog post, he posted an abridged version to
> firefox-dev.
> 
> Mike
> ___
> 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: [RFC] Cleaning up sessionstore.js

[kalle . pihlajasaari]

torstai 28. marraskuuta 2013 13.56.13 UTC+2 David Rajchenbach-Teller kirjoitti:
> As many of you know, Session Restore is something of a performance hog,
> for many reasons - we have reports of. One of the reasons is that we
> store so very many things in sessionstore.js and sometimes keep stuff
> for a very long time.
> 
> As part of bug 943352 & followup, we are considering automatically
> cleanup some of the contents of sessionstore.js. Since people have
> mentioned "webcompat" and "userdata loss" in the context of
> sessionstore.js, I'd appreciate some feedback before we proceed.
> 
> So, here are a few things that I believe we could cleanup:
> 1. get rid of closed windows after a while;
> 2. get rid of closed tabs after a while;
> 3. get rid of old history entries of open tabs after a while;
> 4. get rid of POST data of history entries after a while;
> 5. get rid of DOM storage contents of open tabs after a while;
> 6. get rid of form data content of open tabs after a while;
> ...
> 
> Note that we don't have space usage number for each of these (bug 942340
> should provide more insight).
> 
> If anybody feels that we are going to break one million websites (or one
> million profiles), we would be interested to hear about this.
> 
> Cheers,
>  David
> -- 
> David Rajchenbach-Teller, PhD
>  Performance Team, Mozilla

I have been wrestling with a big sessionstore.js since I discovered tab-groups, 
I have been trying to find remedies to performance and recovery and have not 
found anything.  A few times per year I go looking for inspiration and it seems 
there is little information about the status of these upgrades.

Is there some way to do steps 1 to 6 manually (perhaps a plug-in)?

At many times at the end of a day I like to think that I am at a place that I 
could do a clean-up.

Mostly my tabs are used for side projects and tool groups so they do not need 
historical context, I would just like the URL stored.  I would very much like 
to have the start-up faster, tag group switching faster and less clutter in the 
sessionstore if it were to crash and need recovery.

Leaving more historical data by default could be done in pinned tabs perhaps 
(though not needed by me) and this would be a way to preserve state in those 
tabs that are important to maintain forms data etc.

>From a privacy point of view this is going to become increasingly important.  
>When the session store breaks it often leaves old copies that remain unless 
>manually removed. It would be nice if they contained a bit less old data.

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

TIFU by using Math.random()

[Philip Chee]

Hopefully Spidermonkey's Math.random() is better.

Phil

-- 
Philip Chee , 
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Till Schneidereit]

FWIW, I received questions about this via private email and phone calls
from two people working on extensions that support their products. Their
extensions sit in the review queue with not chance of getting through it
before the signing requirement kicks in. This puts them into a situation
where their only reasonable course of action is to advise their users to
switch browsers.

On Wed, Nov 25, 2015 at 10:31 AM, David Rajchenbach-Teller <
dtel...@mozilla.com> wrote:

> And didn't receive any reply, afaict.
>
> On 25/11/15 10:30, Mike Hommey wrote:
> > On Wed, Nov 25, 2015 at 10:14:09AM +0100, David Rajchenbach-Teller wrote:
> >> I admit I have followed extension signing/scanning only very remotely,
> >> but Dan Stillman has a number of good points:
> >>
> >>
> http://danstillman.com/2015/11/23/firefox-extension-scanning-is-security-theater
> >>
> >> Could someone who's actually involved in this feature provide an answer?
> >
> > As mentioned in the blog post, he posted an abridged version to
> > firefox-dev.
> >
> > Mike
> > ___
> > 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Question: "Chrome file doesn't exist: ..." in |make mozmill| log by running DEBUG versions of C-C TB

[Neil]

ISHIKAWA,chiaki wrote:


Does anybody have an idea of the issue of

> 113 Chrome file doesn't exist: 
/NREF-COMM-CENTRAL/objdir-tb3/dist/bin/chrome/messenger/content/messenger/messengercompose/null 



"null" can't be right.


A test is probably trying to set the src of an image to null instead of 
a real source. (Perhaps it was trying to remove the src? Maybe null 
worked at one point.)


--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: TIFU by using Math.random()

[Xidorn Quan]

According to the article, SpiderMonkey's PRNG is not much better than
V8's. It seems we are using a even older algorithm, although
ironically have a better result.

After reading this article as well as some introduction from the
wikipedia, it seems to me that "xorshift+" is probably the best
algorithm to adopt, because it is simple, fast, and passes all tests
in TestU01 [1], which indicates it should also have a good quality.

I'm not an expert on this, though.


[1] http://xorshift.di.unimi.it/

- Xidorn

On Wed, Nov 25, 2015 at 10:42 PM, Philip Chee  wrote:
> 
>
> Hopefully Spidermonkey's Math.random() is better.
>
> Phil
>
> --
> Philip Chee , 
> http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
> Guard us from the she-wolf and the wolf, and guard us from the thief,
> oh Night, and so be good for us to pass.
> ___
> 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

Web APIs documentation/evangelism/dev team meeting Thursday at 8 AM PST

[Eric Shepherd]

The Web API documentation community meeting, with representatives from
the technical evangelism and the API development teams, will take place
on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your
time zone).

Typical meetings include news about recent API development progress and
future development plans, discussions about what the priorities for
documenting and promoting new Web technologies should be, and the status
of ongoing work to document and evangelize these technologies.

We have an agenda, as well as details on how to join, here:

https://public.etherpad-mozilla.org/p/API-docs-meeting-2015-11-26.

If you have topics you wish to discuss, please feel free to add them to
the agenda.

We look forward to seeing you there!

If you have topics you wish to discuss, please feel free to add them to
the agenda. Also, if you're unable to attend but have information or
suggestions related to APIs on the Web, their documentation, and how we
promote these APIs, please add a note or item to the agenda so we can be
sure to address it, even if you're unable to attend.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla 
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Web APIs documentation/evangelism/dev team meeting Thursday at 8 AM PST

[Eric Shepherd]

> Eric Shepherd 
> November 25, 2015 at 8:14 AM
> The Web API documentation community meeting, with representatives from
> the technical evangelism and the API development teams, will take
> place on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for
> your time zone).
>
> Typical meetings include news about recent API development progress
> and future development plans, discussions about what the priorities
> for documenting and promoting new Web technologies should be, and the
> status of ongoing work to document and evangelize these technologies.
>
> We have an agenda, as well as details on how to join, here:
>
> https://public.etherpad-mozilla.org/p/API-docs-meeting-2015-11-26.
>
> If you have topics you wish to discuss, please feel free to add them
> to the agenda.
>
> We look forward to seeing you there!
>
> If you have topics you wish to discuss, please feel free to add them
> to the agenda. Also, if you're unable to attend but have information
> or suggestions related to APIs on the Web, their documentation, and
> how we promote these APIs, please add a note or item to the agenda so
> we can be sure to address it, even if you're unable to attend.
>
> 
My finger hadn't even finished lifting off the "send" button when I
remembered that this meeting is canceled this week due to the United
States's Thanksgiving holiday. Please ignore this notice.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla 
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: TIFU by using Math.random()

[Frederik Braun]

On 25.11.2015 12:42, Philip Chee wrote:
> 
> 
> Hopefully Spidermonkey's Math.random() is better.
> 
> Phil
> 

There have been multiple insightful responses on HN and reddit/netsec.
The short version is, that Math.random() isn't providing statistically
good randomness, because JS benchmarks use it. So it has been optimized
for performance in most browsers.

Also, the person writing the post did not only want randomness, but
uniqueness. If someone wants unique, you should use a UUID-algorithm.
If all you need is a better PRNG use crypto.getRandomValues(), which is
providing cryptographically secure randomness.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform