Intent to implement and ship `AudioBufferSourceNode.detune`
Summary: This new attribute allows authors to modulate the `.playbackRate` property of the AudioBufferSourceNode in cents (which is a scale that is more useful in a musical context, because logarithmic instead of linear). This also aligns the AudioBufferSourceNodes with other source nodes, that previously had a `.detune` parameter. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1153783 Link to standard: http://webaudio.github.io/web-audio-api/#widl-AudioBufferSourceNode-detune Platform coverage: all Will ship in: 40 Preference behind which this will be implemented: none DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1116852 Other browser support: Blink bug https://code.google.com/p/chromium/issues/detail?id=463279 Tests: dom/media/webaudio/test/test_audioBufferSourceNodeRate.html Thanks, Paul. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
If you're addicted to cleartrext, the future is going to be hard for you... On Tue, Apr 14, 2015 at 2:26 PM, connor.be...@gmail.com wrote: HTTPS has its moments, but the majority of the web does not need it. I certainly wouldn't appreciate the encryption overhead just for visiting David's lolcats website. As one of the most important organizations related to free software, it's sad to see Mozilla developers join the war on plaintext: http://arc.pasp.de/ The owners of websites like this have a right to serve their pages in formats that do not make hypocrites of themselves. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Joseph Lorenzo Hall Chief Technologist Center for Democracy Technology 1634 I ST NW STE 1100 Washington DC 20006-4011 (p) 202-407-8825 (f) 202-637-0968 j...@cdt.org PGP: https://josephhall.org/gpg-key fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
On Wednesday, April 15, 2015 at 6:56:48 AM UTC-7, Joseph Lorenzo Hall wrote: If you're addicted to cleartrext, the future is going to be hard for you... Only because people like you insist on trying to push it across-the-board, rather than let webmasters make their own decisions. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
northrupthebandg...@gmail.com schrieb: That whole article is just additional shovelfuls of bovine manure slopped onto the existing heap. Please refrain from language like that in lists like this if you want to be taken seriously. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
vic schrieb: I would view this proposal favorably if 1) you didn't try to force people to adopt the One True Way and 2) the CA situation was fixed. Please define of what alternatives to what you call the One True Way are acceptable to you and still secure to access, and also what specific issues with the CA system you would want/need to see fixed. It's hard to discuss improvements when you are low on specifics. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
On Wed, Apr 15, 2015 at 10:03 AM, commodorej...@gmail.com wrote: rather than let webmasters make their own decisions. I firmly disagree with your conclusion, but I think you have identified the central property that is changing. Traditionally transport security has been a unilateral decision of the content provider. Consumers could take it or leave it as content providers tried to guess what content was sensitive and what was not. They could never really know, of course. The contents of a public library are not private - but my reading history may or may not be. An indexed open source repository is not private - but my searching for symbols involved in a security bug may be. The content provider can't know apriori and even if they do may not share the interests of the consumer. The decision is being made by the wrong party. The HTTPS web says that data consumers have the right to (at least transport) confidentiality and data integrity all of the time, regardless of the content. It is the act of consumption that needs to be protected as we go through our day to day Internet lives. HTTPS is certainly not perfect at doing this, but its the best thing we've got. So yes, this is a consumer-first, rather than provider-first, policy. -Patrick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
On 2015-04-15 10:03 AM, commodorej...@gmail.com wrote: On Wednesday, April 15, 2015 at 6:56:48 AM UTC-7, Joseph Lorenzo Hall wrote: If you're addicted to cleartrext, the future is going to be hard for you... Only because people like you insist on trying to push it across-the-board, rather than let webmasters make their own decisions. Webmasters are already restricted in how they can run their services in many ways, some standards-based, some inherent to the web as we find it in the wild. For what it's worth I think that the fact that it is (at present) way more difficult to obtain, install, and update a certificate for a web server than it is to obtain, install and update a web server means that _mandating_ HTTPS would represent a real barrier to participation in a free and open Web. Having said that, deprecated clearly doesn't mean prohibited, and the Let's Encrypt's How It Works page suggests that setting up a cert won't be all that difficult in the near future. So, while you may be right that the benefits here seem to be all client side and the up-front costs seem to be all server-side, it looks like work is well underway to reduce server-side costs to almost nothing. Moving from TLS if the server wants to to TLS is what the client expects is a meaningful change in incentive structure underneath web security, and sounds like the right thing to me. - mhoye * https://letsencrypt.org/howitworks/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
Yoav Weiss schrieb: IMO, limiting new features to HTTPS only, when there's no real security reason behind it will only end up limiting feature adoption. It directly punishing developers and adds friction to using new features, but only influence business in a very indirect manner. That's my concern as well, I think we need to think very hard about what reasons people have to still not use TLS and how we can help them to do so. Let's Encrypt will be one step easing the solution to one class of reasons, but there's more. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
Boris Zbarsky schrieb: On 4/14/15 3:28 AM, Anne van Kesteren wrote: On Tue, Apr 14, 2015 at 4:10 AM, Karl Dubost kdub...@mozilla.com wrote: 1. You do not need to register a domain name to have a Web site (IP address) Name one site you visit regularly that doesn't have a domain name. My router's configuration UI. Here regularly is probably once a month or so. And even then, you can get certificates for public IP addresses. It's not a public IP address. We do need a solution for this space, which I expect includes the various embedded devices people are bringing up; I expect those are behind firewalls more often than on the publicly routable internet. Definitely. Right now, esp. those router configs and similar web interfaces to devices are in a very bad state - either they run unencrypted (most of them) or they can only go with self-signed certs with mostly-bogus domain descriptors, which is pretty bad as well, or the user needs to create a cert and install it into the device, which is too much hassle for the vast majority of people. Are there any good proposals on how to make those decently secure and keep them easy to use? KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Runnables and thread-unsafe members
Sounds good to me as well. On 2015-04-14 5:44 PM, Bobby Holley wrote: +1. On Tue, Apr 14, 2015 at 2:42 PM, Kyle Huey m...@kylehuey.com wrote: On Tue, Apr 14, 2015 at 2:39 PM, Randell Jesup rjesup.n...@jesup.org wrote: (was: Re: Proposal to ban the usage of refcounted objects inside C++ lambdas in Gecko) tl;dr: We should make DispatchToMainThread take already_AddRefed and move away from raw ptrs for Dispatches in general. Agreed. - Kyle ___ 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 deprecate: Insecure HTTP
northrupthebandg...@gmail.com schrieb: On Monday, April 13, 2015 at 8:26:59 PM UTC-7, ipar...@gmail.com wrote: * Less scary warnings about self-signed certificates (i.e. treat HTTPS+selfsigned like we do with HTTP now, and treat HTTP like we do with HTTPS+selfsigned now); the fact that self-signed HTTPS is treated as less secure than HTTP is - to put this as politely and gently as possible - a pile of bovine manure I am against this. Both are insecure and should be treated as such. How is your browser supposed to know that gmail.com is intended to serve a self-signed cert? It's not, and it cannot possibly know it in the general case. Thus it must be treated as insecure. Except that one is encrypted, and the other is not. *By logical measure*, the one that is encrypted but unauthenticated is more secure than the one that is neither encrypted nor authenticated, and the fact that virtually every HTTPS-supporting browser assumes the precise opposite is mind-boggling. Right, the transport is encrypted, but it's completely unverified that you are accessing the actual machine you wanted to reach (i.e. there is no domain verification, which is what you need a 3rd-party system for, the CA system being the usual one in the TLS/web realm). You could just as much be connected to a MitM with that encrypted transport. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement and ship AudioContext.{suspend,resume,close}
Summary: AudioContexts are very useful objects, but they use quite a lot of CPU time (they use a very high priority thread that wakes up often to compute and output audio), keep the audio hardware awake and in low latency mode. In other words, authors should try to dispose of their AudioContext when they don't need them. This has been the cause of multiple B2G battery life regression, as the Dialer app uses an AudioContext to output the DTMF tones. This API allow authors to simply `suspend()` the processing for an already existing Web Audio API graph, effectively freezing all time and processing. The high priority thread stops, the audio hardware can go to sleep. When needed again, a call to `resume()` start the processing again. `close()` tells the graph to close its audio output, to release the underlying platform audio stream as fast as possible. This is important because some platforms have a strict and low limit on the number of AudioContext that can simultaneously exist. Since those are inherently asynchronous operation (platform audio APIs can take some time to stop/start, etc.), Promises are returned to notify content that the operation has finished. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1094764 Link to standard: http://webaudio.github.io/web-audio-api/#widl-AudioContext-suspend-Promise-void http://webaudio.github.io/web-audio-api/#widl-AudioContext-close-Promise-void http://webaudio.github.io/web-audio-api/#widl-AudioContext-resume-Promise-void Platform coverage: all Will ship in: 40 Preference behind which this will be implemented: none DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1154794 Other browser support: Blink Tests: dom/media/webaudio/test/test_audioContextSuspendResumeClose.html Thanks, Paul. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
On Wed, Apr 15, 2015 at 5:20 PM, Robert Kaiser ka...@kairo.at wrote: Are there any good proposals on how to make those decently secure and keep them easy to use? I believe Chrome is experimenting with different UI for self-signed certificates when connecting to a local server. A good outline of the problem space is here: https://noncombatant.org/2014/10/12/brainstorming-security-for-the-internet-of-things/ -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
New Developer Tools Feature: prettifying JSON
One of the new features we'd like to have in DevEdition 40 is related to JSON rendering. Dev folks deal with JSON a lot these days and we want to make the work easier by rendering JSON as an expandable tree that allows easy inspection and filter/search. One option to make this is implementing a stream convertor with contract-id: @mozilla.org/streamconv;1?from=application/jsonto=*/html This means that any document with application/json (loaded into a tab) is auto converted into a little HTML app that allows easy inspection. See a screenshot here: http://snag.gy/rHivb.jpg This approach has one security implication, if the page uses default-src 'none' (or other security restrictions?) - injecting JS into it generates warnings: Content Security Policy: The page's settings blocked the loading of a resource at self (default-src 'none'). Another option is introducing specific URL (like: chrome://browser/devtools/jsonviewer.xul) that implements the entire app and avoids JS injection in the existing content. But direct conversion of JSON documents is handy... and perhaps we have yet another option...? What do you think? What approach is the best here? (and without any security concerns) Honza ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
On Wed, Apr 15, 2015 at 10:44:35AM +0100, Gervase Markham wrote: On 14/04/15 22:59, northrupthebandg...@gmail.com wrote: The article assumes that when folks connect to something via SSH and something changes - causing MITM-attack warnings and a refusal to connect - folks default to just removing the existing entry in ~/.ssh/known_hosts without actually questioning anything. https://www.usenix.org/system/files/login/articles/105484-Gutmann.pdf That is somewhat discouraging, but I wonder what the conditions of these organizations are. At the very risky end you could ignore a key change you were not told of ahead of time for my chinese hosting provider. On the other hand if I'm sitting at my desk using my laptop and change the key for the sshd on my desktop there isn't nearly as much risk in ignoring the key my laptop sees. The first important thing to note about this model is that key changes are an expected part of life. Only if they've been communicated first. How does a website communicate with all its users that it is expecting to have (or has already had) a key change? After all, you can't exactly put a notice on the site itself... Well, you can put up a notice while using the old cert, and in principal you can sign the new cert with the old one similar to what you do when changing gpg keys. However in the case the old cert needs to be revoked all users do need to go back to the out of band verification method. You can't provide [Joe Public] with a string of hex characters and expect it to read it over the phone to his bank. Sure you can. Joe Public *already* has to do this with social security numbers, credit card numbers, checking/savings account numbers, etc. on a pretty routine basis, whether it's over the phone, over the Internet, by mail, in person, or what have you. What makes an SSH fingerprint any different? The fact that now you have the letters A through F to read? Please. You have missed the question of motivation. I put up with reading a CC number over the phone (begrudgingly) because I know I need to do that in order to buy something. If I have a choice of clicking OK or phoning my bank, waiting in a queue, and eventually saying Hi. I need to verify the key of your webserver's cert so I can log on to do my online banking. Is it 09F9.? then I'm just going to click OK (or Whatever, as that button should be labelled). I wonder if there's a reasonable way to make it hard to click whatever, but fairly easy to say I expect the finger print for the cert for foo.com is ab:cd:de:fg... if that's correct I'm happy this is secure. As an asside I personally find the manual comparison to be a pain even if I have both finger prints easily available. Trev Gerv ___ 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: New Developer Tools Feature: prettifying JSON
On 4/15/15 12:54 PM, Jan Odvarko wrote: This approach has one security implication, if the page uses default-src 'none' (or other security restrictions?) - injecting JS into it generates warnings: Content Security Policy: The page's settings blocked the loading of a resource at self (default-src 'none'). How does our XML prettyprinter manage this? I seem to recall it force-loads an XBL binding that provides all the scriptability. Does that have the same problem with CSP headers? If not, can you take the same approach here? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Running C-C TB under valgrind during mozmill test: extending timeout values (but where?)
I wonder if someone has any idea about the following issues: I used to be able to run C-C TB under valgrind by creating a wrapper binary during mozmill test. This wrapper is named as .../dist/bin/thunderbird and invokes thunderbird-bin under valgrind. By extending, timeout values in a few places in mozmill script files, I could run this valgrind + TB combination successfully during mozmill test and this helped me uncover about a dozen uninitialized memory references and one out of bound memory reference which was caused by badly crafted Date: line, etc. But after the major build infrastructure change, which eventually led to the use of mozharness, etc., the timeout value changes that I performed no longer are enough to prevent the test framework to timeout prematurely. I could not get valgrind+TB run before the timeout kicks in. I wonder if anyone has an idea of how to extend the timeout value(s) successfully. I checked the source files recently, but there are so many timeout values scattered around in many files, I don't know exactly which ones I should change. (The first timeout I hit is related to connect/setup bridge to running TB, I think.) Another thing is that the comments suggest there is a mixture of timeout values that are in milliseonds and seconds used in the code. From the experience I had until last spring/summer, I am quite sure that the timeout values used for socket timeout, etc. are in milliseconds. However, browsing through a few .py files at the top-level, I noticed that they are commented as seconds and not milliseconds, and so got confused. Maybe the timeout values needs to be multipled by 1000 to make sure that valgrind can run. I have no idea. Any hint / tips regarding how to extend the timeout values globally will be appreciated. (One other thing, these values are embedded inside .py files that are expanded/created during the build process from archive under the source directory, and so I have to modify the .py files JUST BEFORE running tests. If there is a way to change the values in the archive so that they will persist, that will be great.) I need to make sure TB won't crash due to these memory issues during normal usage and that is why I want to test it throughly. TIA ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: New Developer Tools Feature: prettifying JSON
Jan, Le 16 avr. 2015 à 01:54, Jan Odvarko odva...@gmail.com a écrit : One of the new features we'd like to have in DevEdition 40 is related to JSON rendering. Prettifying JSON is a good idea. Did you check/play with jq? https://stedolan.github.io/jq/ https://jqplay.org/ They do a really good job at showing and understanding the data. This is mostly a text-based UI with syntax coloring but it's very effective as it gives me the power at the tips of my hands. Not constrained by a choice of UI. Talking about prettifying, it would be nice if we could have user themes (maybe textmate/sublime theme language) to be able to choose the rendering/prettifying rules for JSON, HTML, JS, etc. -- Karl Dubost, Mozilla http://www.la-grange.net/karl/moz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
As Robert is saying: Le 16 avr. 2015 à 00:29, Robert Kaiser ka...@kairo.at a écrit : I think we need to think very hard about what reasons people have to still not use TLS and how we can help them to do so. Definitely. The resistance in this thread is NOT about people against security, but 1. we want to be able to choose 2. if we choose safe, we want that choice to be easy to activate. # Drifting Socially, eavesdropping is part of our daily life. We go to a café, we are having a discussion and people around you may listen what you are saying. You read a book in the train, a newspaper and people might see what you are reading. We adjust the type of discussions depending on the context. The café is too dangerous, too privacy invasive and we decide to go to a safer environment, sometimes a safer environment is not necessary being hidden (encryption), but being more public. As I said contexts. (Note above my usage of the word safe and not secure) # Back to the topic It's important for the user to understand the weaknesses and the strength of the environment so they can make a choice. You could almost imagine that you do not care to be plain text until a moment where you activate a secure mode. (change of place in the cafe) Also we need to think in terms of P2P communications, not only broadcaster-consumers (1-to-many). If the Web becomes something which is harder and harder to start hacking on and communicating with your peers, then we reinforce the power of big hierarchical structures and we change the balance that Web brought over the publishing/media industry. We should always strive for bringing the tools that empower individual people with their ideas and expressions. Security is part of it. But security doesn't necessary equate to safer. It's just a tool that can be used in some circumstances. Do we want to deprecate HTTP? Or do we want to make it more obvious when the connection is not secure? These are two very different things. -- Karl Dubost, Mozilla http://www.la-grange.net/karl/moz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
RE: changing the default platform and operating-system on bugzilla.mozilla.org to all / all
+1 to suggestions from Lawrence and Milan. The info is still pretty important for the QA team, and we definitely do NOT want it gone. Regards, Florin. -Original Message- From: dev-platform [mailto:dev-platform-bounces+florin.mezei=softvisioninc...@lists.mozilla.org ] On Behalf Of Byron Jones Sent: Wednesday, April 15, 2015 7:03 AM To: Lawrence Mandel Cc: Milan Sreckovic; Benjamin Smedberg; dev-platform@lists.mozilla.org; Dave Townsend Subject: Re: changing the default platform and operating-system on bugzilla.mozilla.org to all / all Lawrence Mandel wrote: +1 to Milan's suggestion. These fields are used somewhat consistently on stability and graphics bugs, which release management pays attention to. If we are going to continue with the fields, I like the idea of Not specified as that makes it clear that no value was set whereas All is currently used if the bug affects all platforms or if we don't know. thanks for the feedback. defaulting to unspecified instead of all is a great idea. i've updated the bug and will proceed along that path unless there are strong objections (keeping in mind that individual products will still be able to default to all/all should the owners desire that). -glob -- byron jones - :glob - bugzilla.mozilla.org team lead - ___ 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 deprecate: Insecure HTTP
On Wed, Apr 15, 2015 at 12:10 PM, Gervase Markham g...@mozilla.org wrote: 2) Reduced privacy. And that's why the connection would be marked as insecure in the UI. We need to move away from HTTPS being able to go into an insecure state. We can't expect the user to keep an eye on the address bar the whole time. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
On 14/04/15 22:59, northrupthebandg...@gmail.com wrote: The article assumes that when folks connect to something via SSH and something changes - causing MITM-attack warnings and a refusal to connect - folks default to just removing the existing entry in ~/.ssh/known_hosts without actually questioning anything. https://www.usenix.org/system/files/login/articles/105484-Gutmann.pdf The first important thing to note about this model is that key changes are an expected part of life. Only if they've been communicated first. How does a website communicate with all its users that it is expecting to have (or has already had) a key change? After all, you can't exactly put a notice on the site itself... You can't provide [Joe Public] with a string of hex characters and expect it to read it over the phone to his bank. Sure you can. Joe Public *already* has to do this with social security numbers, credit card numbers, checking/savings account numbers, etc. on a pretty routine basis, whether it's over the phone, over the Internet, by mail, in person, or what have you. What makes an SSH fingerprint any different? The fact that now you have the letters A through F to read? Please. You have missed the question of motivation. I put up with reading a CC number over the phone (begrudgingly) because I know I need to do that in order to buy something. If I have a choice of clicking OK or phoning my bank, waiting in a queue, and eventually saying Hi. I need to verify the key of your webserver's cert so I can log on to do my online banking. Is it 09F9.? then I'm just going to click OK (or Whatever, as that button should be labelled). Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
On 14/04/15 17:46, j...@chromium.org wrote: I just wanted to mention that regarding subresource integrity (https://w3c.github.io/webappsec/specs/subresourceintegrity/), the general consensus over here is that we will not treat origins as secure if they are over HTTP but loaded with integrity. We believe that security includes confidentiality, which that would approach would lack. --Joel Radical idea: currently, the web has two states, insecure and secure. What if it still had two states, with the same UI, but insecure meant HTTPS top-level, but some resources may be loaded using HTTP with integrity, and secure meant HTTPS throughout? That is to say, we don't have to tie the availability of new features to the same criteria as we tie the HTTP vs. HTTPS icon/UI in the browser. We could allow powerful features for HTTPS-top-level-and-some-HTTP-with-integrity, while still displaying it as insecure. Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: mochitest is() now uses ===
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, Bug 949614 landed yesterday, making the is() function in mochitests compare its argument with === rather than ==. is_loosely() has been introduced (hopefully temporarily) with is()'s old behaviour; ise() is now simply an alias for is(). Thanks to everyone who helped bring this home! Ms2ger -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJVLhlwAAoJEOXgvIL+s8n27TEH/RTBfCQmN0dwDzzRGPsYT9ya ztmFfpJq2NKe85YX9XnO+yLha9Lvc2V83J4SHRC0PpJgKEfgR3DAswCDnX+MOD3e 7PfXqkY6ceVhrrPz1b0TxWWCnVvW9OyjlxhAjH7k8K96T0uBvcrB3q0AKFLC4aXH RhzHWGxnaP1jzG1JIpLbVELobBXTuKDHOA4jnEMpaksrgttrVzk1b4gnaJF/CuMF mhFM0x1hKR/0dS3XKF9XAFMmbErRh9b9lOzg5s87+dGXyEkJg7POT7ozCFn6WHDb ehRvtFqgtHLeqM62IAwk1t9XmqZvP/rvrBQECbR7MRqfmomTtzdKw+BuO2867qY= =YIyD -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
On 14/04/15 13:32, Eric Shepherd wrote: My main concern with the notion of phasing out unsecured HTTP is that doing so will cripple or eliminate Internet access by older devices that aren't generally capable of handling encryption and decryption on such a massive scale in real time. While it may sound silly, those of us who are intro classic computers and making them do fun new things use HTTP to connect 10 MHz (or even 1 MHz) machines to the Internet. These machines can't handle the demands of SSL. So this is a step toward making their Internet connections go away. If this is important to you, then you could simply run them through a proxy. That's what jwz did when he wanted to get Netscape 1.0 running again: http://www.jwz.org/blog/2008/03/happy-run-some-old-web-browsers-day/ Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: nsIStreamConverter e10s
Yes, the platform bug seems to be related. I commented in the report. Honza On 10 Apr 2015, at 18:11, Gabor Krizsanits gkrizsan...@mozilla.com wrote: I'm working on a bug that might be related (https://bugzilla.mozilla.org/show_bug.cgi?id=982319 https://bugzilla.mozilla.org/show_bug.cgi?id=982319). Could you provide me some more details about the issue you have? In general it's a bit tricky area, are you trying to convert the stream on the parent or on the child side? What is your exact set-up and what does not work? Any case, filing bug is probably a good idea... Gabor On Fri, Apr 10, 2015 at 4:42 PM, Jan Odvarko odva...@gmail.com mailto:odva...@gmail.com wrote: I created a (JS) component that implements nsIStreamConverter (JSON - HTML), but it doesn't seem to work in e10s. Is this suppose to work? Is there a bug for this? Honza ___ dev-platform mailing list dev-platform@lists.mozilla.org mailto:dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform 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 deprecate: Insecure HTTP
On 14/04/15 16:39, david.a.p.ll...@gmail.com wrote: There are already multiple sources of free publicly-trusted certificates, with more on the way. https://www.startssl.com/ https://buy.wosign.com/free/ https://blog.cloudflare.com/introducing-universal-ssl/ https://letsencrypt.org/ I think that you should avoid making this an exercise in marketing Mozilla's Let's Encrypt initiative. Perhaps that's why Richard took the time to make a comprehensive list of all known sources of free certs, rather than just mentioning LE? Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
On Wed, Apr 15, 2015 at 11:50 AM, Gervase Markham g...@mozilla.org wrote: Radical idea: currently, the web has two states, insecure and secure. What if it still had two states, with the same UI, but insecure meant HTTPS top-level, but some resources may be loaded using HTTP with integrity, and secure meant HTTPS throughout? HTTPS already has mixed content, we should not make it worse. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
On 15/04/15 10:59, Anne van Kesteren wrote: HTTPS already has mixed content, we should not make it worse. What's actually wrong with mixed content? 1) The risk of content tampering. Subresource integrity makes that risk go away. 2) Reduced privacy. And that's why the connection would be marked as insecure in the UI. Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
