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
+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:
>>
>>
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
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
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
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
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
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.
>
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
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
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:
> 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:
>> 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:
> 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
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
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
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:
> 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
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
>
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
___
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
;> *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
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
;>> Matt
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>>
>>
>>
>> --
>> Dav
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'
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
/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
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
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
29 matches
Mail list logo
