Summary: The WebCrypto spec [1] states that window.crypto.subtle
should only be usable from a secure origin (i.e. on a domain being
served over HTTPS). Currently Gecko's implementation works on insecure
origins (i.e. sites served over unencrypted HTTP). To bring our
implementation in line with the
+1
A separate channel sounds like a great idea. And it will help
dealing with two very different kinds of information.
On Sat, Nov 4, 2017 at 5:38 PM, Simon Sapin wrote:
> On 04/11/17 17:21, Zibi Braniecki wrote:
>>
>> +1
>>
>> The only thing I'd like to see from pulsebot on developers is:
>>
>>
t is not then treated as insecure
> despite the risk being pretty much the same.
>
> On Thu, Jul 20, 2017 at 3:47 PM, Tim Taubert wrote:
>>
>> Summary: The WebCrypto spec [1] states that window.crypto.subtle
>> should only be usable from a secure origin (i.e. on a domain
Ben Kelly wrote:
> Can we just reduce the accuracy of the API? Only give battery level at
> certain broad breakpoints?
The authors of the cited paper [1] filed a bug report and we fixed that
for 38 [2].
- Tim
[1] http://eprint.iacr.org/2015/616.pdf
[2] https://bugzilla.mozilla.org/show_bug.cgi
/process-releases/draft/development_overview/
>> Ancient,
>> and shows it, but still relevant for this case. See "Moving work from
>> one channel to another"
>>
>> ---
>> Johnathan Nightingale
>> VP Firefox Engineering
>> @johnath
>>
>
>
--
Tim Taubert
Firefox Engineer
ttaub...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
e purview of the build config module. But I
> wanted to run the proposal by people to make sure it is generally
> well-received and there aren't any major concerns.
>
> Gregory
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https
On 07/18/2013 02:45 PM, Benjamin Smedberg wrote:
> On 7/18/2013 2:43 AM, Tim Taubert wrote:
>> The proposal sounds good to me but I guess you wouldn't want to be
>> notified of every small addition/change to Makefiles in test
>> directories? I suppose you'
;>> Matt
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>>
>>
>>
>> --
>> Dav
ing to use JavaScript.
The number of pings per link is currently limited to 1
(browser.send_pings.max_per_link). Chrome does not limit the number of
pings, we should look into raising or disabling the limit.
- Tim
--
Tim Taubert
Engineering Manager, Firefox
;> *Notes*
>> The navigator.sendBeacon() API is a superset of .
>> allows for lightweight navigation pings without having to use JavaScript.
>>
>> The number of pings per link is currently limited to 1
>> (browser.send_pings.max_per_link). Chrome does not limit
Anne van Kesteren wrote:
> On Fri, May 16, 2014 at 12:20 PM, Tim Taubert wrote:
>> Calling the whole idea of "disturbing" makes it sound like we
>> would introduce a whole new concept, we just provide a saner way to do
>> things that lots of web pages want. Ther
seems valid at first but we
can't even prevent that right now. If sites want to and will do that
anyway we should at least provide a way that has less disadvantages for
the user.
- Tim
--
Tim Taubert
Engineering Manager, Firefox
@ttaubert
___
L. David Baron wrote:
> We need to be careful to design the preferences we expose to the
> user in ways that make sense even if sites don't want to honor those
> preferences. It's not clear to me that it makes sense to have a
> preference to disable one particular tracking feature when sites can
>
Curtis Koenig wrote:
> Given our stance on privacy[1] and commitment to Real Choices, Sensible
> Settings and User Control; I don’t believe removing the users ability to
> control this preference would be a positive move. David’s point is more
> correct in that we need to be careful as to how th
Curtis Koenig wrote:
> Would this be disabled in Private Browsing? If not that might be perceived as
> negating one of the reasons users have for using that particular feature.
Are sync XHRs and HTTP redirects disabled in private browsing? :)
- Tim
___
Curtis Koenig wrote:
> Assuming I am understanding this correctly, it appears from this doc
> https://developer.mozilla.org/en-US/docs/Supporting_per-window_private_browsing
> that they maybe disabled in some instances of private browsing given changes
> in Fx 20.
The only thing I can see here
Jonathan Kew wrote:
> On 16/5/14 14:37, Kyle Huey wrote:
>> On Fri, May 16, 2014 at 6:30 AM, Curtis Koenig
>> The point being made is that the preference is not a real choice. If
>> you disable this feature you can still be tracked in the exact same
>> way by methods that exist today and are not
Tobias Besemer wrote:
> Am Donnerstag, 26. Juni 2014 17:33:22 UTC+2 schrieb Tobias Besemer:
> OK, I was redirected in bug 810932 to this group for discussions about how to
> change/improve the sessionstore ...
Thanks for moving the discussion here.
> ... so I now want to start the discussion wit
Tobias Besemer wrote:
>> What problems are you currently hitting that you think will be fixed by
>> downsizing sessionstore.js?
> I have ~4-8 GB I/O because of ss on a 8h day. Please look at the bugs you
> have commented before.
I looked at those bugs and they don't have better problem descriptio
Tobias Besemer wrote:
> The ss is necessary, when e.g. a user editing a large text in a wiki, haven't
> saved that text yet, and closes this page as a mistake. So he can go back /
> undo close and still have his un-saved text ...
Yes, this was the reason why sessionstore was introduced years ago
Tobias Besemer wrote:
> The amount of I/O is always a problem! E.g. for Notebooks in battery use.
Yes, of course. That is a known problem and we're working on it by
increasing the write interval when running on battery and working
towards a journaled storage.
As I said before, cleaning sessionsto
Tobias Besemer wrote:
> Am Samstag, 28. Juni 2014 14:25:35 UTC+2 schrieb Tim Taubert:
>> Tobias Besemer wrote:
>>
>>> The amount of I/O is always a problem! E.g. for Notebooks in battery use.
>> Yes, of course. That is a known problem and we're working on it
As of September we intend to enable the WebCrypto API by default on all
platforms. It has been developed behind the dom.webcrypto.enabled
preference.
Tracking bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=865789
Spec:
https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html
(A CR
gzilla.mozilla.org/show_bug.cgi?id=1037892
> Thanks!
> Ehsan
>
> On 2014-09-03, 1:36 PM, Tim Taubert wrote:
>> As of September we intend to enable the WebCrypto API by default on all
>> platforms. It has been developed behind the dom.webcrypto.enabled
>> preference.
>
helpcrypto helpcrypto wrote:
> I'll love to know if Mozilla/Firefox is going to provide something (even
> out-of-standard) to make possible using PKCS#11/NSS with Webcrypto.
The WebCrypto API basically exposes PKCS#11/NSS functionality with a DOM
API.
> This will fill the gap that currently exist
Dirkjan Ochtman wrote:
> Is there a list of algorithms we support somewhere, particularly the
> ones we share with Chromium? IIRC the supported algorithms is where
> the real interop problems are expected to be. (I quickly searched MDN,
> but that didn't turn up anything useful.)
Richard Barnes ma
Anne van Kesteren wrote:
> In Chromium the methods only work on authenticated origins. What is
> our story?
Completely agree with Ehsan and Henri. I don't know of any plans to even
consider doing that and we currently expose the WebCrypto API to
unauthenticated origins as well.
> Is the non-overl
On 10/10/2012 11:57 PM, Justin Lebar wrote:
> The main reason I'd want Linux PGO is for mobile. On desktop Linux,
> most users (I expect) don't run our builds, so it's not a big deal if
> they're some percent slower. (Unless distros commonly do PGO builds
> of Firefox?) But we're not doing mobil
On 10/11/2012 09:32 AM, Boris Zbarsky wrote:
> The suggestion, as far as I can tell, is to drop Linux PGO completely.
> We woudln't have it in nightly, Aurora, Beta, or releases. Compiling
> with PGO on Linux would be an unsupported configuration that we'd
> probably advise distros against, becaus
29 matches
Mail list logo
