Re: Intent to Remove: Insecure use of WebCrypto
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
+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 Sapinwrote: > 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
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?
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
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
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
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
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
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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
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
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
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
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
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
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