Re: Intent to Remove: Insecure use of WebCrypto

[Tim Taubert]

On Fri, Jul 28, 2017 at 10:15 PM, Jonathan Kingston <j...@mozilla.com> wrote:
> Hey Tim,
>
> The only questions I have about this our are difference in implementation
> over Chrome the more we increase the use of [SecureContext] the greater risk
> we put on compat bugs.

Good news, the implementation difference was just removed by Kate in
bug 1410364.

Let's move forward with the proposal for Firefox 59.

> Our implementation differs in that we actually abide to the specification on
> window.opener insecure contexts making the openee insecure. This may for
> example cause breakage on payment sites that want to use crypto.
>
> Perhaps we should shift to using SecureContextIfOpenerIgnored instead; at
> least for the time being?
>
> The difference is somewhat a technicality anyway as the inverse isn't true a
> SecureContext that opens an !SecureContext 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 <ttaub...@mozilla.com> wrote:
>>
>> 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 spec, we're going to remove access to
>> crypto.subtle on non-secure origins.
>>
>> Sites using the WebCrypto API's crypto.subtle interface on a
>> non-secure origin should switch to HTTPS as soon as possible.
>>
>> Chrome too is planning to remove access to crypto.subtle on non-secure
>> origins [2]. Edge seems positive about implementing those restrictions
>> as well [3].
>>
>> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1333140
>>
>> Standard: https://w3c.github.io/webcrypto/Overview.html
>>
>> Platform coverage: This will affect Windows, MacOS, Linux, and Android.
>>
>> Estimated target date: This could land as early as Firefox 56, but
>> should in Firefox 57. We probably want to coordinate with Chrome, they
>> seem as ready as we are.
>>
>> Our telemetry [4] indicates that about 9% of crypto.subtle use is
>> still on insecure origins. This was at around 1-2% - that's not the
>> percentage of all users, but only of those that visit pages that use
>> crypto.subtle - but became inflated around two weeks after we started
>> measuring. The blink-dev thread [2] has a good summary and indicates
>> that this is caused by Twitter launching AMP support serving from
>> origins which may be insecure. AMP has a fallback that is lazy-loaded
>> in case crypto.subtle isn't available, so no one's Twitter would break
>> when we ship this.
>>
>>
>> [1] https://w3c.github.io/webcrypto/Overview.html#crypto-interface
>> [2]
>> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/ZD3NWqkk-bo/discussion
>> [3] https://github.com/w3c/webcrypto/issues/28#issuecomment-243243989
>> [4] https://mzl.la/2ttx8aV
>> ___
>> 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: Pulsebot in #developers

[Tim Taubert]

+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:
>>
>> "26 commits have been merged from autoland into mozilla-central.
>> List:http://...;
>
>
> Even that would probably be still be high traffic. A separate channel would
> allow interested people to opt-in.
>
> --
> Simon Sapin
>
> ___
> 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

Intent to Remove: Insecure use of WebCrypto

[Tim Taubert]

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 spec, we're going to remove access to
crypto.subtle on non-secure origins.

Sites using the WebCrypto API's crypto.subtle interface on a
non-secure origin should switch to HTTPS as soon as possible.

Chrome too is planning to remove access to crypto.subtle on non-secure
origins [2]. Edge seems positive about implementing those restrictions
as well [3].

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1333140

Standard: https://w3c.github.io/webcrypto/Overview.html

Platform coverage: This will affect Windows, MacOS, Linux, and Android.

Estimated target date: This could land as early as Firefox 56, but
should in Firefox 57. We probably want to coordinate with Chrome, they
seem as ready as we are.

Our telemetry [4] indicates that about 9% of crypto.subtle use is
still on insecure origins. This was at around 1-2% - that's not the
percentage of all users, but only of those that visit pages that use
crypto.subtle - but became inflated around two weeks after we started
measuring. The blink-dev thread [2] has a good summary and indicates
that this is caused by Twitter launching AMP support serving from
origins which may be insecure. AMP has a fallback that is lazy-loaded
in case crypto.subtle isn't available, so no one's Twitter would break
when we ship this.


[1] https://w3c.github.io/webcrypto/Overview.html#crypto-interface
[2] 
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/ZD3NWqkk-bo/discussion
[3] https://github.com/w3c/webcrypto/issues/28#issuecomment-243243989
[4] https://mzl.la/2ttx8aV
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Fingerprinting of battery status?

[Tim Taubert]

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?id=1124127


 On Tue, Aug 4, 2015 at 11:02 AM, Chris Hofmann chofm...@mozilla.com wrote:
 
 I've seen a lot of GPS related tracking apps that use a lot of power
 putting up warnings to users
 that it might be time to go to low power mode and shut down the GPS if
 you'll need it
 later for navigating a critical pathway later in your journey.

 -chofmann

 On Mon, Aug 3, 2015 at 7:49 PM, Katelyn Gadd k...@luminance.org wrote:

 Games for mobile phones, handheld devices, and laptops often show a
 battery indicator and/or a clock in the corner of the screen while
 running in fullscreen mode. That's the only good reason I can think of
 off-hand.

 On 3 August 2015 at 12:55, Chris Peterson cpeter...@mozilla.com wrote:
 What is a legitimate use case for a web page to know my battery status?
 Battery level and time remaining can be used to fingerprint users.

 A mobile webapp might use battery level to throttle its activity, but
 that
 could be something the OS handles by pausing or throttling apps
 directly
 or
 broadcasting app lifecycle events. I can't think of a good reason why a
 web
 page in a browser, especially on a desktop OS, needs to know anything
 about
 my battery.


 http://www.theguardian.com/technology/2015/aug/03/privacy-smartphones-battery-life
 http://eprint.iacr.org/2015/616.pdf


 chris
 ___
 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

 ___
 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: Intent to ship: WebCrypto API

[Tim Taubert]

Ehsan Akhgari wrote:
 Can you please clarify what are the areas that we don't fully adhere to
 the spec?  Do we expect the fixes to those and potentially new spec
 issues in the future to break backwards compatibility?

KeyAlgorithms were recently changed to dictionaries (from interfaces)
and we did not get around to change that yet. Richard Barnes has a patch
almost ready in bug 1037892 [1] though.

We didn't have to change tests to make them work with KeyAlgorithm
dictionaries so that change would not break existing code. We would
probably aim to land it before enabling WebCrypto by default anyway.

Other parts we're missing is import/export for some formats (e.g. PKCS8
for ECDH/DH) and we're missing a few algorithms completely. We only need
more time to implement those but that wouldn't break any existing code
either.

- Tim

[1] https://bugzilla.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.

 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 is planned soon, only smaller changes to the spec lately.)

 Reasoning:
 The implementation of the WebCrypto API has made lots of progress in
 Firefox 33+34. We added most of the basic functionality and algorithms,
 and should be mostly spec compliant.

 Chromium has had the WebCrypto API enabled by default since Crome 37,
 which was released in late June 2014. Their implementation supports a
 subset of the algorithms that we do, and has roughly the same level of
 spec compliance. We expect the two implementations to be mostly
 interoperable as-is, with some fine points being ironed out as the spec
 is finalized.

 We thus propose to enable the WebCrypto API by default for all platforms
 to get some more feedback from developers and give them the opportunity
 to use new functionality.

 - Tim
 ___
 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: Intent to ship: WebCrypto API

[Tim Taubert]

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 with hardware token support

Not sure what exactly what you are referring to here but I don't know of
any current plans to extend the WebCrypto API beyond what the spec says.

- Tim

 (which, is going to be discussed nexr 10th September)
 Regards.
 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: WebCrypto API

[Tim Taubert]

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 made a nice list of algorithms [1] we support and the
Firefox version they were introduced. A similar list [2] exists for
Chromium, but I can't tell how up-to-date that is. Judging from their
list of tests [3] this seems to indeed list of all of the available
algorithms.

- Tim

[1]
https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AiAcidBZRLxndE9LWEs2R1oxZ0xidUVoU3FQbFFobkEusp=sharing#gid=1
[2]
https://docs.google.com/document/d/184AgXzLAoUjQjrtNdbimceyXVYzrn3tGpf3xQGCN10g/edit?pli=1
[3]
https://chromium.googlesource.com/chromium/blink/+/master/LayoutTests/crypto/

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

Re: Intent to ship: WebCrypto API

[Tim Taubert]

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-overlap of algorithms documented on MDN?

We currently have no documentation for the WebCrypto API other than for
crypto.getRandomValues(). It should certainly be documented on MDN and
we could provide a list of algorithms we support. Not sure whether we
would want to do that for Chromium's supported algorithms as well?

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

Intent to ship: WebCrypto API

[Tim Taubert]

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 is planned soon, only smaller changes to the spec lately.)

Reasoning:
The implementation of the WebCrypto API has made lots of progress in
Firefox 33+34. We added most of the basic functionality and algorithms,
and should be mostly spec compliant.

Chromium has had the WebCrypto API enabled by default since Crome 37,
which was released in late June 2014. Their implementation supports a
subset of the algorithms that we do, and has roughly the same level of
spec compliance. We expect the two implementations to be mostly
interoperable as-is, with some fine points being ironed out as the spec
is finalized.

We thus propose to enable the WebCrypto API by default for all platforms
to get some more feedback from developers and give them the opportunity
to use new functionality.

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

Re: Session Restore (sessionstore)

[Tim Taubert]

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 with my idea, that ss.js should 
 forget the most things when Firefox gets closed manual by the user, 
 originally posted here: 
 https://bugzilla.mozilla.org/show_bug.cgi?id=810932#c22

To properly set the stage for this discussion, why exactly do you want
this? Where do you see the problem with a big sessionstore.js file?
What problems are you currently hitting that you think will be fixed by
downsizing sessionstore.js?

 So what do others / the developers think about this ???

I do agree with the two other posts, I don't want any of my data gone
automatically. Some weeks ago we landed a patch[1] that automatically
purges closed/windows and tabs that are older than two weeks. I still am
not a big fan of that but it seemed worth trying without causing too
much harm. Turns out that this patch doesn't actually achieve[2] what it
should.

As said above I think it would be great to get some basic questions
answered before we talk about purging data. Maybe there are other ways
to mitigate the problems you're seeing. We shouldn't talk about a
specific solution before stating the problem.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=989393
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=989393#c20

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

Re: Session Restore (sessionstore)

[Tim Taubert]

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 descriptions
either unfortunately.

Why is the amount of I/O a problem for you exactly? We unfortunately do
not have a journaled storage but we are working towards it. I doubt that
removing data on Firefox shutdown would solve your problem as most of
the writes happen when Firefox is running.

Is it just the sheer amount of I/O that you dislike? If yes, why? Have
you taken a look at all the other I/O caused by places, cache, etc. and
how that compares?

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

Re: Session Restore (sessionstore)

[Tim Taubert]

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.
Today sessionstore provides much more than just crash recovery and a lot
of people rely on it.

 IMHO this scenario is so unlikely, that is makes no scene, to keep a lot of 
 data in the ss for each user by a manual close with the default settings.

You are evading my questions and still haven't answered why the amount
of I/O you say you're seeing is a problem for you. Instead of
re-iterating your proposal and what you think we should be doing it
would be great if you could tell us why the current behavior is a
problem for you.

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

Re: Session Restore (sessionstore)

[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 by
increasing the write interval when running on battery and working
towards a journaled storage.

As I said before, cleaning sessionstore data on write will not buy you
much as we write a lot when Firefox is running. This is the problem
we're tackling in the long run and band-aid fixes won't help here.

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

Re: Session Restore (sessionstore)

[Tim Taubert]

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 by
 increasing the write interval when running on battery and working
 towards a journaled storage.

 As I said before, cleaning sessionstore data on write will not buy you
 much as we write a lot when Firefox is running. This is the problem
 we're tackling in the long run and band-aid fixes won't help here.
 
 It is not just a question of battery!
 Too much writing accesses also harms the life-time of HDs or SSDs!

Yup, that's why we're working on it. Clearing data on quit won't get us
there as data accumulates while browsing again and probably 90+% of the
I/O happens while Firefox is running.

 I also asked before (on the bugs) about more informations to the journaled 
 storage ...

Great, but as I said we are working towards it. We don't know any
details yet.

 If it is - like I think - a lot of small files, I don't like it!

Ok.

 A lot of small files wast a lot of un-used bytes on the storage and brings a 
 big fragmentation to it! This significantly slows down a system!

File systems have a lot of counter measures nowadays so that might not
be as relevant anymore but I don't know for sure. We haven't decided on
any journaled storage yet and we will be looking into multiple options,
writing our own storage or taking an existing one. Performance and I/O
will of course be important factors.

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

Re: Intent to ship: Hyperlink Auditing (a ping)

[Tim Taubert]

Jonathan Kew wrote:
 When I click a Google search result (for example), I can see -- thanks
 to the status overlay that shows the URLs being requested -- that it's
 redirecting me via a Google URL that is presumably being used to track
 me. So although this is hardly an optimal UI, at least I get a clue that
 the site is doing something more than simply giving me a link that I
 follow, and if I want to avoid telling Google which results I'm
 clicking, I need to somehow work around this.

Google and DuckDuckGo are hiding these, when hovering a search result
link I don't see that the browser will request a different page first
and redirect me afterwards. I think for the average user this is hardly
different from not seeing any hint at all.

 If this is replaced by the use of a ping on those search results, then
 (AFAICT) there will no longer be *any* clue to alert me as a user to the
 fact that the site is monitoring which result I click on. This allows
 pages to more easily track me without ever bringing it to my attention.
 So I do think there's a disadvantage here.

The argument we make it easier to track 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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Hyperlink Auditing (a ping)

[Tim Taubert]

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
 do that sort of tracking in many other ways that aren't controlled
 by the preference.

That's a great point. I think it really might make sense to remove the
preferences altogether as the number of pings per link limit and the
same hosts requirement can actually be worked around quite easily and
would make websites just fall back to the same bad behavior that we
currently have. Ensuring this feature works as expected would surely
drive adoption a lot better.

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

Re: Intent to ship: Hyperlink Auditing (a ping)

[Tim Taubert]

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 the preference is exposed. We 
 could also do something very innovative in this case like what is done with 
 do not track. We could default to allowing all requests (which would honor 
 the spec) but allow the users to change the pref to 2 other states. One being 
 only allow pings from the sites I specify and the final one being don’t allow 
 any at all. With accompanying text that explains the tradeoffs/benefits/pain 
 of each setting. This would help us both keep inline with the goal of 
 Hyperlink Auditing and balance our stance on privacy.

I am all for real choice and keeping the user in control but offering
these preferences does nothing but pretend to protect users and their
privacy. If there is a chance the user might have turned it off without
the site noticing then websites will just keep on doing what they do
currently. Without any chance for the user to intervene or limit, and
without a way to notice this is happening. And with all the current
performance impacts.

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

Re: Intent to ship: Hyperlink Auditing (a ping)

[Tim Taubert]

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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Hyperlink Auditing (a ping)

[Tim Taubert]

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 is that I can force single
requests/channels into private mode, which means they won't persist
cookies, sessionStorage, cache entries, etc. All other means of tracking
navigation by rewriting links before clicking and then redirecting, or
firing a sync XHR do still work and probably can't be disabled because
they would break the web.

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

Re: Intent to ship: Hyperlink Auditing (a ping)

[Tim Taubert]

Jonathan Kew wrote:
 On 16/5/14 14:37, Kyle Huey wrote:
 On Fri, May 16, 2014 at 6:30 AM, Curtis Koenig curt...@mozilla.com
 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 covered by the preference.
 
 Yes; but the methods being used by at (least some major) sites are
 visible to the user, which makes them less insidious than an
 invisible-by-design tracking feature.

I doubt that the common user will notice any of these tracking measures.
Even I wouldn't notice if I don't pay attention or the network would not
sometimes be slow to load.

 If we implement a ping, and make it on-by-default (but with a user
 preference to turn it off), we can reasonably expect sites to use this
 as their tracking method in place of redirects, etc. And if they hten
 detect (can they?) that the user has turned off pings and fall back to
 other methods to track the user - who by disabling it has expressed a
 desire not to be tracked - this puts them in much the same category as
 those who decide to stop honoring Do Not Track.

Web pages can't detect whether pings are actually sent, they know when
those arrive at their endpoints. Thus if a website is concerned about
Firefox users having turned this feature off they might just keep it the
way it currently is and thus be sure it works for every user.

 We can't force sites to honor DNT, and we can't prevent them working
 around user-disabled a ping. But in both cases we can and should (IMO)
 provide a simple means for the user to express a wish about tracking.
 Respectable sites will interoperate nicely with it; those that decide to
 circumvent it should be publicly shamed.

Using DNT is a flawed comparison, DNT is very much only about letting
websites know without the ability to prevent any of that tracking.
Websites can't tell whether a ping is enabled and thus there is no
real point in shaming any of them when we can't even prove they're not
using a ping because some users might have turned it off.

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

Re: Removing a window from the session store

[Tim Taubert]

On 25/10/2013 12:24 PM, Matthew Gertner wrote:
 So if I understand correctly, a window that contains a single private tab 
 will have no visual indication that the tab is private and will also not be 
 restored by the session saver? This would meet my current requirements as 
 long as it's possible to set the tab to private after creation (since I won't 
 know until shutdown whether I want the window to be restored or not).

Private tabs will be automatically excluded when bug 899276 has landed.
I don't know off-hand if setting a tab to private works even if the tab
has been around for some time but I think that might be possible.

 That said, this seems like a worse hack than what I am doing now.

Maybe, yes.

 Why are you getting rid of the nsISupportsString in sessionstore-state-write? 
 Is there some urgency to doing this?

There is no urgency but we're currently in the process of rebuilding
big parts of SessionStore to make it perform better. Giving add-ons that
much access to data makes it really hard to implement any kind of caching.

 Can't you fix https://bugzilla.mozilla.org/show_bug.cgi?id=930713 before you 
 remove it? This seems like a pretty big lack in the current session saver API 
 and something that should be straightforward to implement.

I understand that this feature seems important to you but I disagree
that is a big lack in the current API. This is the first time I hear
of a requirement like that.

Could you maybe describe what you are actually trying to achieve and
why? Is there any add-on code we could take a look at? Maybe we can
together find a different and better solution to your problem.

- Tim



 Cheers,
 Matt
 
 On Oct 25, 2013, at 11:40 AM, David Rajchenbach-Teller dtel...@mozilla.com 
 wrote:
 
 We have partial handling of private tabs. SessionStore doesn't handle
 them yet, but I can prioritize this. Would this be sufficient for your
 needs?

 Cheers,
 David

 On 10/25/13 9:11 AM, Matthew Gertner wrote:
 Can you suggest some other means to do what we need? I don't want to make 
 anyone's life harder but I spent far too long on this problem and didn't 
 come up with another solution.

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



 -- 
 David Rajchenbach-Teller, PhD
 Performance Team, Mozilla
 
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform
 


-- 
Tim Taubert
Firefox Engineer
ttaub...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal: requiring build peer review for Makefile.in changes

[Tim Taubert]

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're targeting actual changes to dependencies
etc, but where do we draw the line?

Can we maybe add a push hook intelligent enough to separate actual
changes from minor changes that don't need build peer review by scanning
for certain keywords?

- Tim


On 07/18/2013 02:00 AM, Gregory Szorc wrote:
 Traditionally, it's been very difficult for the build peers to keep on
 top of changes in the build config because changes are occurring on bug
 components we don't follow, are touching files all over the tree, and
 because build peers aren't always asked for review.
 
 The potential for sneaking things past build peer review has resulted
 in a number of self-inflicted wounds, the Fennec build rules probably
 being the best example (the dependencies are all wrong and no-op builds
 take ~16s when they should take 1 or 2s).
 
 This history contributed to us implementing a more strict sandbox in
 moz.build files: take away as many footguns as possible and there will
 be less self-inflicted wounds.
 
 Unfortunately, the moz.build conversion isn't finished and it will drag
 on for a while. There will still be Makefile.in in the tree and that
 leaves the door open for new badness.
 
 I would like to reinforce the existing policy: *if you are changing a
 Makefile.in, please ask a build peer for review unless the change is
 just adding or removing to an existing list.*
 
 For the most part, people have been abiding by this policy. However,
 things are still creeping through. Unfortunately, some of them wouldn't
 get r+ from a build peer.
 
 Since new Makefile.in badness makes people's lives harder (especially
 when it makes the build slower), I would like to propose a more strict
 policy around Makefile.in changes: *if a non-list change in a
 Makefile.in isn't reviewed by a build peer, it doesn't land or gets
 backed out.* This could potentially be enforced with repository push hooks.
 
 I /think/ this proposal is supported by our module governance system
 since Makefile.in are the 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://lists.mozilla.org/listinfo/dev-platform
 


-- 
Tim Taubert
Firefox Engineer
ttaub...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal: requiring build peer review for Makefile.in changes

[Tim Taubert]

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're targeting actual changes to dependencies
 etc, but where do we draw the line?
 I thought the proposed exception was pretty clear: unless the change is
 just adding or removing to an existing list.

Indeed, it was. Sorry, I must have missed that.

- Tim


-- 
Tim Taubert
Firefox Engineer
ttaub...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [Advance warning] Session Restore is changing, will break add-ons

[Tim Taubert]

I talked to Gavin yesterday and we think the best approach would be to
back out the Session Restore changes for now as they don't provide a
real benefit other than code cleanup (and don't block any other work).

The plan would then be to re-land them *with* a kill switch in the same
cycle that brings Australis - so we would need to prepare and keep those
patches ready. The reasoning is that we indeed will break different
add-ons than Australis but at least there will only be one release with
a couple of add-ons breaking instead of two in a row.

For bug 838577 we will probably need to maintain a shadow tree as
Johnathan mentioned. I would suggest we talk to Ehsan as he has
experience in doing this successfully.

- Tim


On 05/22/2013 03:40 PM, David Rajchenbach-Teller wrote:
 Opening Bug 874817 to add that kill switch.
 
 Just for clarification: we might kill add-ons that specifically look at
 the contents of undocumented private data structures. The advance
 warning is here because we know that some such add-ons exist.
 
 Given that all these refactorings take place on a single file, it might
 make sense to just backout the changes if necessary.
 
 Cheers,
  David
 
 On 5/22/13 3:35 PM, Johnathan Nightingale wrote:
 Policy[1] is that whenever something lands on central, it is the
 developer's responsibility to provide for the ability to turn it off.
 Usually that's just a kill switch in cases where it makes sense, or a
 backout where the patch is unlikely to accumulate much change on top of
 itself in a given release.  

 In cases where neither of those works (Ehsan's private browsing changes,
 or dmandelin's landing of ionmonkey in FF18) engineers have had to work
 harder to maintain that ability, e.g. by maintaining a shadow tree that
 doesn't have their patches, but has all the other landings. That's what
 Ehsan's pointing to in his reply.

 I agree with Ehsan that, one way or another, we'll need to be able to
 disable these changes if they cause too much bustage (though I'm very
 happy to know that we're cleaning up that code in general).

 J


 [1] http://mozilla.github.io/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

Re: Proposal: Remove Linux PGO Testing

[Tim Taubert]

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 mobile Linux PGO builds (that I know
 of), and I don't expect success with desktop PGO is much related to
 success with mobile PGO.

You may be right for release builds but that doesn't hold true for
Nightly/Aurora/Beta users. I don't think it's a good idea to make those
builds ~20% slower when of course we want and need more testers. Don't
forget that testers on Linux do not only test Linux-only features but
also features we have on every platform.

Nobody likes running debug builds because they're slower so why would
that be different for non-PGO builds?

Also, I'm not sure how this affects Telemetry results. In terms of perf
measurements we'd probably need to completely ignore everything from
non-release builds as the results might differ heavily for some use
cases.

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

Re: Proposal: Remove Linux PGO Testing

[Tim Taubert]

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, because it wouldn't be particularly
 well-tested.

Yes, if we don't distribute PGO builds at all we'd see a one-time bump
and Telemetry is then a non-issue. I was misguided by the thread's
title. If we turn it off for testing we can't ship it.

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