Re: How does stl_wrappers works in mozilla building system?
On Fri, Apr 17, 2015 at 2:58 PM, Yonggang Luo wrote: > I can not found the cause that how mozilla building with stl_wrappers. > What do you want to know? https://dxr.mozilla.org/mozilla-central/search?tree=mozilla-central&q=stl_wrapper&redirect=true clearly shows a Python script that generates the wrapper header files and also where the includes are added in configure.in. Not standard but easy to see the broad strokes. Nick > ___ > 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
How does stl_wrappers works in mozilla building system?
I can not found the cause that how mozilla building with stl_wrappers. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
How does stl_wrappers works in mozilla building system?
I can not found the cause that how mozilla building with stl_wrappers. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
Karl Dubost schrieb: Henri, great points, about… Le 14 avr. 2015 à 19:29, Henri Sivonen a écrit : Currently, the UI designation for http is neutral while the UI designation for mixed content is undesirable. I think we should make the UI designation of plain http undesirable once x% the sites that users encounter on a daily basis are https. What about changing the color of the grey world icon for http into something which is more telling. An icon that would mean "eavesdropping possible". but yes UI should be part of the work. I believe we could think about potentially starting with only marking HTTP that contains any script as insecure. There's much less danger of evesdropping or other stuff on completely static HTML+CSS that doesn't contain any scripts or iframes or somesuch. Of course, we'd need to get some data to find out if completely static/passive sites vs. those with scripts etc. make any significant difference in terms of how many sites are affected. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
On Fri, Apr 17, 2015 at 11:22 AM, Anne van Kesteren wrote: > As I said early on in this thread, this claim often comes up, but is > never backed up. Where is the research that shows we need public > caching proxies? This is early days, but I'm working with a partner on two things: - working out how to cache https resources - working out if it's worthwhile doing I can share what material I have on the topic; it's very rough right now and we have no actual data, but I expect the project to be in a better shape as things progress. This is all part of the overall plan to make HTTPS as usable as possible. The latter question is a real concern, but we won't know until we go and collect some data. When we get measurements for these sorts of things, it's usually from services that have the resources to acquire the measurements. At the same time, those services likely have the resources to have a CDN and so probably will have less need for caches. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
On Fri, Apr 17, 2015 at 6:46 PM, Mike Hoye wrote: > I don't see where that document speaks to the impact of TLS on caching > proxies, which I'm guessing is the source of the performance hit Andrew > mentions. > > It's been a while since I've looked, but in Canada (and probably other > geographically large countries) the telcos/ISP with large exurban/rural > client bases used to use caching proxies a lot. As I said early on in this thread, this claim often comes up, but is never backed up. Where is the research that shows we need public caching proxies? -- 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 04/17/2015 09:46 AM, Mike Hoye wrote: On 2015-04-17 12:20 PM, Anne van Kesteren wrote: On Fri, Apr 17, 2015 at 6:13 PM, wrote: As a non-tech person, the only thing I know is https means my browser runs even slower on DSL. This has already been addressed earlier in the thread. HTTPS has negligible performance impact. See e.g.: https://istlsfastyet.com/ I don't see where that document speaks to the impact of TLS on caching proxies, which I'm guessing is the source of the performance hit Andrew mentions. It's been a while since I've looked, but in Canada (and probably other geographically large countries) the telcos/ISP with large exurban/rural client bases used to use caching proxies a lot. From my past experience with satellite based connections https was appreciably slower than http. I don't know how much of the affect was due to the loss of the caching proxy or how much was due to the latency+handshake issue. This was also several years ago and I don't have experience with the improved networking in Firefox over satellite . In third world countries, such as the United States, many people in rural areas are limited to satellite base connections and may be adversely affected by the move to encrypted connections. This isn't to say we shouldn't move to encryption, just that the network experience in major metropolitan areas isn't indicative of what someone in rural Virginia might experience for example. /bc ___ 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-17 12:20 PM, Anne van Kesteren wrote: On Fri, Apr 17, 2015 at 6:13 PM, wrote: As a non-tech person, the only thing I know is https means my browser runs even slower on DSL. This has already been addressed earlier in the thread. HTTPS has negligible performance impact. See e.g.: https://istlsfastyet.com/ I don't see where that document speaks to the impact of TLS on caching proxies, which I'm guessing is the source of the performance hit Andrew mentions. It's been a while since I've looked, but in Canada (and probably other geographically large countries) the telcos/ISP with large exurban/rural client bases used to use caching proxies a lot. - mhoye ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
On Fri, Apr 17, 2015 at 6:13 PM, wrote: > As a non-tech person, the only thing I know is https means my browser runs > even slower on DSL. This has already been addressed earlier in the thread. HTTPS has negligible performance impact. See e.g.: https://istlsfastyet.com/ > Meanwhile: "Deprecate" it?? Has anyone in the tech community used an English > dictionary? http://en.wikipedia.org/wiki/Deprecation#Software_deprecation -- 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
As a non-tech person, the only thing I know is https means my browser runs even slower on DSL, which is all that is available in many rural areas. Would this not mean that I'd be back to dial-up times to load a story or post, all of which are larded up with ads and videos these days? At 7 mbps tops, my browsing is already difficult. Meanwhile: "Deprecate" it?? Has anyone in the tech community used an English dictionary? To deprecate Http would mean to speak badly of it. Or disapprove of it. I think you mean you want to abolish it, pressure it out of existence, or create a disincentive to use it. ___ 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 3:33 AM, Karl Dubost wrote: > Le 14 avr. 2015 à 19:29, Henri Sivonen a écrit : >> Currently, the UI designation for http is neutral while the UI >> designation for mixed content is undesirable. I think we should make >> the UI designation of plain http undesirable once x% the sites that >> users encounter on a daily basis are https. > > What about changing the color of the grey world icon for http into something > which is more telling. > An icon that would mean "eavesdropping possible". but yes UI should be part > of the work. I indeed meant changing the grey globe icon to something else eventually, but I deliberately wanted to avoid starting a bikeshed in *this* thread about what the new icon should be. Usually something on the theme of the Eye of Sauron comes up in discussion about the icon. > For Web Compatibility, dropping non secure cookies would be an interesting > survey to do and see how much it breaks (or not) the Web and user experience. Note that I didn't propose dropping support for insecure cookies right away. I proposed forgetting (by default) insecure cookies when quitting Firefox. At least at the start, it would probably make sense not to forget cookies from sites that the users has put in the explicit "Allow" category in the cookie manager. AFAICT, this can't "Break the Web" for the usual definition of that phrase, since the forgetting behavior wouldn't be site-detectable in mid-browsing. It would affect the UX on non-https login-requiring sites (including ones whose login is https but whose session cookie is insecure to allow everything except supposedly sensitive things like sending the password or sending a credit card number happen over http due to legacy performance memes), which are, as noted, Doing It Wrong. -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
