Re: Excessive inbound bustage

[Neil]

Mike Hommey wrote:


the biggest number of changesets pushed by someone without a backout in the 
last 25271 changesets is 126.


But what's their Try usage like?

--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[richard . barnes]

On Thursday, April 23, 2015 at 11:47:14 PM UTC-4, voracity wrote:
> Just out of curiosity, is there an equivalent of:
> 
> python -m SimpleHTTPServer
> 
> in the TLS world currently, or is any progress being made towards that?

openssl req -new -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem
openssl s_server -accept 8000 -key key.pem -cert cert.pem -HTTP

Not quite as simple, but not far off.  With the above, you can get 
, as long as you're willing to click through a 
certificate warning.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[rbarnes]

On Friday, April 24, 2015 at 1:03:00 AM UTC-4, butrus...@gmail.com wrote:
> On Monday, April 13, 2015 at 4:57:58 PM UTC+2, Richard Barnes wrote:
> > There's pretty broad agreement that HTTPS is the way forward for the web.
> > In recent months, there have been statements from IETF [1], IAB [2], W3C
> > [3], and even the US Government [4] calling for universal use of
> > encryption, which in the case of the web means HTTPS.
> > 
> > In order to encourage web developers to move from HTTP to HTTPS, I would
> > like to propose establishing a deprecation plan for HTTP without security.
> > Broadly speaking, this plan would entail  limiting new features to secure
> > contexts, followed by gradually removing legacy features from insecure
> > contexts.  Having an overall program for HTTP deprecation makes a clear
> > statement to the web community that the time for plaintext is over -- it
> > tells the world that the new web uses HTTPS, so if you want to use new
> > things, you need to provide security.  Martin Thomson and I drafted a
> > one-page outline of the plan with a few more considerations here:
> > 
> > https://docs.google.com/document/d/1IGYl_rxnqEvzmdAP9AJQYY2i2Uy_sW-cg9QI9ICe-ww/edit?usp=sharing
> > 
> > Some earlier threads on this list [5] and elsewhere [6] have discussed
> > deprecating insecure HTTP for "powerful features".  We think it would be a
> > simpler and clearer statement to avoid the discussion of which features are
> > "powerful" and focus on moving all features to HTTPS, powerful or not.
> > 
> > The goal of this thread is to determine whether there is support in the
> > Mozilla community for a plan of this general form.  Developing a precise
> > plan will require coordination with the broader web community (other
> > browsers, web sites, etc.), and will probably happen in the W3C.
> > 
> > Thanks,
> > --Richard
> 
> 
> I think this is very very bad idea. There are many resources which are not 
> worth being protected by HTTPS. Moreover, it doesn't make sense e.g. for 
> resources in the local network. And there are devices which CANNOT use HTTPS, 
> e.g. a webserver on a 8-bit MCU (like 
> http://tuxgraphics.org/electronics/200611/article06111.shtml).
> 
> So, please, let it be the responsibility of the webmaster and/or the user 
> whether to use HTTP or HTTPS!

To be clear, we are not proposing to remove that choice, only limiting the set 
of web features that non-HTTPS pages can use.

There are also plenty of small platforms that can support HTTPS.  Slightly 
bigger than what you're talking about, but still small.
http://hypernephelist.com/2014/08/19/https_on_arduino_yun.html

--Richard


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

Re: Tiles Design Questions (was Re: Improving trust and transparency for Suggested Tiles)

[Mike Hoye]

On 2015-04-24 12:07 AM, Eric Rescorla wrote:
Who said anything about excluded? It's simply much easier to discuss 
detailed topics in a small real-time setting. If there are community 
members who are well-prepared for this discussion, I don't see why 
they couldn't be participants.
There's no practical difference between a meeting that explicitly 
excludes the Mozilla community and one that's not widely announced ahead 
of time and is difficult or impossible to participate in remotely.


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

Re: Tiles Design Questions (was Re: Improving trust and transparency for Suggested Tiles)

[Eric Rescorla]

On Fri, Apr 24, 2015 at 7:05 AM, Mike Hoye  wrote:

> On 2015-04-24 12:07 AM, Eric Rescorla wrote:
>
>> Who said anything about excluded? It's simply much easier to discuss
>> detailed topics in a small real-time setting. If there are community
>> members who are well-prepared for this discussion, I don't see why they
>> couldn't be participants.
>>
> There's no practical difference between a meeting that explicitly excludes
> the Mozilla community and one that's not widely announced ahead of time and
> is difficult or impossible to participate in remotely.
>

If people have something useful to say then they should presumably ask to
be included in the meeting. If they can't be bothered to do that, that seems
like a fairly trivial form of exclusion.

To be clear: nobody is saying that whatever comes out of such a meeting
shouldn't be surfaced publicly for community comment, but that doesn't
mean that it's not useful to have a more focused discussion with the people
who are actually well-prepared to have it.

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

Re: Tiles Design Questions (was Re: Improving trust and transparency for Suggested Tiles)

[Mike Hoye]

On 2015-04-24 10:14 AM, Eric Rescorla wrote:
On Fri, Apr 24, 2015 at 7:05 AM, Mike Hoye > wrote:


On 2015-04-24 12:07 AM, Eric Rescorla wrote:

Who said anything about excluded? It's simply much easier to
discuss detailed topics in a small real-time setting. If there
are community members who are well-prepared for this
discussion, I don't see why they couldn't be participants.

There's no practical difference between a meeting that explicitly
excludes the Mozilla community and one that's not widely announced
ahead of time and is difficult or impossible to participate in
remotely.


If people have something useful to say then they should presumably ask to
be included in the meeting.


"But Mr Dent, the plans have been available in the local planning office 
for the last nine months."


"Oh yes, well as soon as I heard I went straight round to see them, 
yesterday afternoon. You hadn't exactly gone out of your way to call 
attention to them, had you? I mean, like actually telling anybody or 
anything."


"But the plans were on display ..."

"On display? I eventually had to go down to the cellar to find them."

"That's the display department."

"With a flashlight."

"Ah, well the lights had probably gone."

"So had the stairs."

"But look, you found the notice didn't you?"

"Yes," said Arthur, "yes I did. It was on display in the bottom of a 
locked filing cabinet stuck in a disused lavatory with a sign on the 
door saying 'Beware of the Leopard'."





- mhoye

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

Re: Intent to deprecate: Insecure HTTP

[Mike Hoye]

On 2015-04-24 1:02 AM, butrus.but...@gmail.com wrote:
I think this is very very bad idea. There are many resources which are 
not worth being protected by HTTPS.

This is about protecting people, not resources.

I think an eight-year-old article about a hacked-up, homebrew 8-bit 
webserver is the edgiest of edge case I've ever seen, but there's a seed 
of an idea in there about embedded devices that's important.


The common case there, though, will be home users who do not know the 
first thing about network security but have a house full of wireless 
embedded devices and appliances, not the lo-fi hacker community who 
you'd expect to have a better sense of what they're in for. In that 
context HTTPS is a security measure you expect to be there by default, 
as basic and universal as the locks on your front door.



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

Re: Tiles Design Questions (was Re: Improving trust and transparency for Suggested Tiles)

[Eric Rescorla]

On Fri, Apr 24, 2015 at 7:20 AM, Mike Hoye  wrote:

>  On 2015-04-24 10:14 AM, Eric Rescorla wrote:
>
>  On Fri, Apr 24, 2015 at 7:05 AM, Mike Hoye  wrote:
>
>> On 2015-04-24 12:07 AM, Eric Rescorla wrote:
>>
>>> Who said anything about excluded? It's simply much easier to discuss
>>> detailed topics in a small real-time setting. If there are community
>>> members who are well-prepared for this discussion, I don't see why they
>>> couldn't be participants.
>>>
>>  There's no practical difference between a meeting that explicitly
>> excludes the Mozilla community and one that's not widely announced ahead of
>> time and is difficult or impossible to participate in remotely.
>>
>
>  If people have something useful to say then they should presumably ask to
> be included in the meeting.
>
>
>  "But Mr Dent, the plans have been available in the local planning office
> for the last nine months."
>
> "Oh yes, well as soon as I heard I went straight round to see them,
> yesterday afternoon. You hadn't exactly gone out of your way to call
> attention to them, had you? I mean, like actually telling anybody or
> anything."
>
> "But the plans were on display ..."
>
> "On display? I eventually had to go down to the cellar to find them."
>
> "That's the display department."
>
> "With a flashlight."
>
> "Ah, well the lights had probably gone."
>
> "So had the stairs."
>
> "But look, you found the notice didn't you?"
>
> "Yes," said Arthur, "yes I did. It was on display in the bottom of a
> locked filing cabinet stuck in a disused lavatory with a sign on the door
> saying 'Beware of the Leopard'."
>
Yes, that's exactly like having a meeting to figure out a preliminary plan
and then
publishing it for public comment.

-Ekr


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

Re: Tiles Design Questions (was Re: Improving trust and transparency for Suggested Tiles)

[Philip Chee]

On 24/04/2015 04:02, Martin Thomson wrote:
> On Thu, Apr 23, 2015 at 12:33 PM,   wrote:
>> Do you have suggestions on where each of the 4 topics I posted
>> should be discussed?
> 
> In a meeting, where a small number of participants are
> well-prepared.

[qoute]We were asked to involve the dev.planning community sooner to
allow for discussions and feedback instead of presenting a decision that
was made in a small group,[/quote]

Phil

-- 
Philip Chee , 
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Tiles Design Questions (was Re: Improving trust and transparency for Suggested Tiles)

[Chris Hofmann]

I think this discussion has moved a bit off topic.

Let's all assume that if the intent was to gather public feedback by a post
in the newsgroup that a similar intent of having a meeting with interested
participant would include a good sampling of people with interest, and that
their employment status with Mozilla wouldn't matter.  Those have always
been the assumptions at mozilla.

I think the key thing that missing in this tiles discussion goes back to a
good thing that lilly once said:

"...Tell me what you're trying to do, and tell me your assumptions; then I
can give you feedback."

I think that's what's missing from Ed's initial post.

We got bits and pieces of a few parts of suggest tiles, but not an
explanation of what this is trying to do for users and possible
advertisers.  What's needed are more details and assumptions how it might
connect them closer or not, and some more details about how the overall
system to generate the selection for a given tile is intended to work.

>From there an explanation and discussion about how these pieces respect
user privacy and tracking choices, and value for the involved parties can
proceed.  That's how we can get to a conversation that might discover any
unintended side effects or mitigation strategies that don't really work
that the orginal plan might not have considered.

-chofmann

On Fri, Apr 24, 2015 at 7:35 AM, Eric Rescorla  wrote:

> On Fri, Apr 24, 2015 at 7:20 AM, Mike Hoye  wrote:
>
> >  On 2015-04-24 10:14 AM, Eric Rescorla wrote:
> >
> >  On Fri, Apr 24, 2015 at 7:05 AM, Mike Hoye  wrote:
> >
> >> On 2015-04-24 12:07 AM, Eric Rescorla wrote:
> >>
> >>> Who said anything about excluded? It's simply much easier to discuss
> >>> detailed topics in a small real-time setting. If there are community
> >>> members who are well-prepared for this discussion, I don't see why they
> >>> couldn't be participants.
> >>>
> >>  There's no practical difference between a meeting that explicitly
> >> excludes the Mozilla community and one that's not widely announced
> ahead of
> >> time and is difficult or impossible to participate in remotely.
> >>
> >
> >  If people have something useful to say then they should presumably ask
> to
> > be included in the meeting.
> >
> >
> >  "But Mr Dent, the plans have been available in the local planning office
> > for the last nine months."
> >
> > "Oh yes, well as soon as I heard I went straight round to see them,
> > yesterday afternoon. You hadn't exactly gone out of your way to call
> > attention to them, had you? I mean, like actually telling anybody or
> > anything."
> >
> > "But the plans were on display ..."
> >
> > "On display? I eventually had to go down to the cellar to find them."
> >
> > "That's the display department."
> >
> > "With a flashlight."
> >
> > "Ah, well the lights had probably gone."
> >
> > "So had the stairs."
> >
> > "But look, you found the notice didn't you?"
> >
> > "Yes," said Arthur, "yes I did. It was on display in the bottom of a
> > locked filing cabinet stuck in a disused lavatory with a sign on the door
> > saying 'Beware of the Leopard'."
> >
> Yes, that's exactly like having a meeting to figure out a preliminary plan
> and then
> publishing it for public comment.
>
> -Ekr
>
>
> >
> >
> > - mhoye
> >
> ___
> 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

May I execute mozIStorageStatement.executeAsync() at the same time in a single thread?

[Yonggang Luo]

I am currently using executeAsync to do async sqlite operation
in main thread, and running multiple executeAsync  in parallel, and it's 
crashed,
I am not so sure if multiple executeAsync can be executed at the same time.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: May I execute mozIStorageStatement.executeAsync() at the same time in a single thread?

[Andrew Sutherland]

On 04/24/2015 12:48 PM, Yonggang Luo wrote:

I am currently using executeAsync to do async sqlite operation
in main thread, and running multiple executeAsync  in parallel, and it's 
crashed,
I am not so sure if multiple executeAsync can be executed at the same time.


This is fine.  The executeAsync calls aren't run in parallel.  Each 
database connection gets its own async thread.  All async operations for 
that connection are run serially on the async thread.


I'd suggest getting a backtrace from any crash to determine where things 
are actually going wrong.  But especially if you're using an older 
version of gecko/firefox, if mozStorage is the source of the crashes, 
you'll want to make sure:

- You're correctly using asyncClose to shutdown the connection.
- You're not trying to invoke things after using asyncClose

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

Enabling Pointer Events in Firefox (desktop) Nightly

[Matt Brubeck]

tl;dr:

We plan to enable Pointer Events for mouse and pen input in Firefox Nightly 
builds within the next few weeks.

Background:

Pointer Events is a W3C recommendation that defines new DOM events for unified 
handling of mouse, touch, and pen input.  It also defines a new 'touch-action' 
CSS property for declarative control over touch panning and zooming behavior:

http://www.w3.org/TR/pointerevents/

The 'touch-action' CSS property is shipping today in both IE11 and Chrome 
stable.  The DOM PointerEvent API is shipping today in IE11, and the Chrome 
team plans to ship it soon.

Status:

Implementation of pointer events and 'touch-action' in Gecko has been in 
progress for several months.  Both features can be enabled in Firefox Nightly 
with prefs, currently off by default.  When these prefs are turned on:

* Events for mouse input are supported on Windows, Mac, and Linux.
* Events for pen input are supported on Windows.
* Events for multi-touch input, and the 'touch-action" property, are a work in 
progress on Windows.  These features depend on e10s, and on Async Pan/Zoom 
(APZ) which is currently preffed off by default on desktop.
* PointerEvent and 'touch-action' are not yet implemented on Android or Firefox 
OS, though in the long term much of the code will be shared between all 
platforms, through the APZ controller.

Plans:

The implementation of Pointer Events should be complete enough to enable in 
desktop Nightly builds within the next few weeks.  This will enable Pointer 
Events for mouse and pen input.  (It will also enable Pointer Events for 
multi-touch input on Windows when e10s and APZ are enabled, though like APZ 
itself this is still experimental and will not yet be turned on by default.)

If no serious problems are found, then we want to consider letting this feature 
ride the train to the Aurora/Dev.Edition channel (but not further).

For the release and beta channels, we may want to wait until after touch input 
is ready to ship on Windows (depends on e10s + APZ), and we might also want to 
wait until it is ready to ship on Android and/or Firefox OS at the same time or 
soon after.  When the time is closer, we will send an "Intent to Ship" email to 
this list for discussion.

See also:

This wiki page has some links to tracking bugs and other information:
https://wiki.mozilla.org/Gecko/Touch
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Retiring the monolithic test package

[Christopher Manchester]

This message is about bug 917999 - "Split test package into per-suite
packages", more can be found there.

I'm working on a set of patches to do this, but the assumption that a build
comes with a "tests.zip" that has all of the tests to run against that
build seems likely to be a part of more tools than I'm aware of. If you
maintain such a tool, please file a bug blocking 917999 and adjust your
tool based on the information below and/or contact me directly. I'll do
what I can to help.

If you have a tool that looks for a tests.zip in order to run tests, that
tool may need to be modified to keep working. We're planning to do this in
mozharness by uploading a manifest that will map from test harness names
('mochitest', 'cppunittests', etc) to a list of file names that are the
test packages required for that harness. In most cases there is a "common"
zip and a zip specifically including the harness' support files and tests
(in cases a harness' name does not appear in the manifest, that harness has
not been split, and everything required to run that harness will be in the
common zip).

I'm planning to have this done and landed by the end of the quarter, and
likely by the end of May.

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

Re: May I execute mozIStorageStatement.executeAsync() at the same time in a single thread?

[David Rajchenbach-Teller]

By the way, I don't know if you're writing JS code or C++ code, but if
it's the former, you really should use Sqlite.jsm.

Cheers,
 David

On 24/04/15 18:48, Yonggang Luo wrote:
> I am currently using executeAsync to do async sqlite operation
> in main thread, and running multiple executeAsync  in parallel, and it's 
> crashed,
> I am not so sure if multiple executeAsync can be executed at the same time.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
> 


-- 
David Rajchenbach-Teller, PhD
 Performance Team, Mozilla



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

(mozci) Triggering jobs on treeherder

[Armen Zambrano G.]

Hello all,
We wrote last quarter a project called Mozilla CI tools (mozci) which 
allows triggering jobs on treeherder. [1]


This is specially useful for back-filling jobs (specially when 
coalesced) and bisecting via job triggering.


Specifically, I want to bring to your attention a use case to help 
developers with pushing to try and using the wrong try syntax [2]. If 
you read the blog post or use cases and think of other useful use cases 
please let us know.


We want to bring to mach only the use cases which make sense to you.

Kudos to @vaibhav, @adusca, @jmaher et al for their large record of 
contributions [3].


regards,
Armen

PS=Support for B2G will be added this quarter

[1] 
http://armenzg.blogspot.ca/2015/04/what-mozilla-ci-tools-is-and-what-it.html
[2] 
http://mozilla-ci-tools.readthedocs.org/en/master/use_cases.html#case-scenario-8-developer-needs-to-add-missing-platforms-jobs-for-a-try-push

[3] https://github.com/armenzg/mozilla_ci_tools/graphs/contributors
--
Zambrano Gasparnian, Armen
Automation & Tools Engineer
http://armenzg.blogspot.ca
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: (mozci) Triggering jobs on treeherder

[Gijs Kruitbosch]

Are you going to build a web UI for this so I don't need to check out a 
repo and run a python script with syntax that I'll likely need to look 
up every time I want to do it, guessing builder names that I don't know?


(don't get me wrong, I could probably use it if I needed to, but it's 
harder than it could be right now...)


It seems to me like self-serve does a lot of this, but you can't 
"retrigger" things that haven't run in the first place.


~ Gijs

On 24/04/2015 21:34, Armen Zambrano G. wrote:

Hello all,
We wrote last quarter a project called Mozilla CI tools (mozci) which
allows triggering jobs on treeherder. [1]

This is specially useful for back-filling jobs (specially when
coalesced) and bisecting via job triggering.

Specifically, I want to bring to your attention a use case to help
developers with pushing to try and using the wrong try syntax [2]. If
you read the blog post or use cases and think of other useful use cases
please let us know.

We want to bring to mach only the use cases which make sense to you.

Kudos to @vaibhav, @adusca, @jmaher et al for their large record of
contributions [3].

regards,
Armen

PS=Support for B2G will be added this quarter

[1]
http://armenzg.blogspot.ca/2015/04/what-mozilla-ci-tools-is-and-what-it.html

[2]
http://mozilla-ci-tools.readthedocs.org/en/master/use_cases.html#case-scenario-8-developer-needs-to-add-missing-platforms-jobs-for-a-try-push

[3] https://github.com/armenzg/mozilla_ci_tools/graphs/contributors


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

Re: (mozci) Triggering jobs on treeherder

[Mike Hommey]

On Fri, Apr 24, 2015 at 10:26:58PM +0100, Gijs Kruitbosch wrote:
> Are you going to build a web UI for this so I don't need to check out a repo
> and run a python script with syntax that I'll likely need to look up every
> time I want to do it, guessing builder names that I don't know?
> 
> (don't get me wrong, I could probably use it if I needed to, but it's harder
> than it could be right now...)
> 
> It seems to me like self-serve does a lot of this, but you can't "retrigger"
> things that haven't run in the first place.

Why not have these features on treeherder?

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

Re: Intent to deprecate: Insecure HTTP

[Roger Hågensen]

On Tuesday, April 21, 2015 at 2:56:21 PM UTC+2, Gervase Markham wrote:
> Very briefly:
> 
> On 21/04/15 12:43, Roger Hågensen wrote:
> > 1. User downloads a browser (be it Firefox, Chrome, Opera, etc.)
> > securely (https?) from the official download location. 2. Upon
> > installation a private key is created for that browser installation
> > and signed by the browser's certificate server. 
> 
> This makes checking in with the browser maker a necessary prerequisite
> for secure connections. That has problems.

How so? Certificates have to be checked today as well (if they have been 
revocated or not).
Also, it would only be at installation time for the user.
The server itself would heck if it's been revocated or not.
StartSSL uses client certificates for logins, so does several other sites.

If you an have a client-server connection where only the server has a 
certifiate then the opposite is also possible, where the client-server 
connection is secured with only the client having a certificate.

> > 3. When the user
> > later connect to a server that support automatic encryption, the
> > browser sends a (public) session key that the server should use, this
> > key is signed with the browser installation key, the server can
> > verify the signature and that this key is not modified by checking
> > the certificate server.
> 
> What you just built is a unique identifier for every browser which can
> be tracked across sites.

How can this be tracked? This can be tracked just like any other client 
certificate can be tracked currently, no difference.

> > 4. The server exchanges it's session key with
> > the browser. 5. A secure/encrypted connection is now possible.
> 
> Except that the browser has not yet identified the site. It is important
> for the user to check the site is genuine before the user sends any
> important information to it.
> 
> > The benefit is that there is no server side certificates needed to
> > establish a encrypted connection. 
> 
> They are needed if the user wants to have any confidence in who they are
> actually talking to.

DNSSEC exists and should help mitigate who you are talking to issue.
Also certificates have been falsified (didn't Mozilla just untrust all 
certificates by a certain certificate issuer recently that allowed fake 
Google.com certificates to be made?)

Also with certificates like the free ones from StartSSL the only site identity 
you can see is "identity not verified" yet the connection is still HTTPS. Just 
look at https://skuldwyrm.no/ which uses a free StartSSL certificate.
Do note however that this .no domain do have DNSSEC enabled (does all latest 
browsers support that?)
So one can be relatively sure to be talking to skuldwyrm.no without https.

What I'm proposing is no worse than automatic domain verified certificates 
currently are.
The important thing is that the connection is encrypted here.
Not whether the site is trusted or not.
Heck, there are sites with a "green url bar" that do rip people off, so trust 
or ensuring you do'nt get fooled is not automagic with any type of HTTPS in 
that regard.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Roger Hågensen]

On Tuesday, April 21, 2015 at 3:56:31 PM UTC+2, Mike Hoye wrote:
> On 2015-04-21 6:43 AM, Roger Hågensen wrote:
> > I know, not that well explained and over simplified. But the concept 
> > is hopefully clear, but in case it's not...
> For what it's worth, a lot of really smart people have been thinking 
> about this problem for a while and there aren't a lot of easy buckets 
> left on this court. Even if we had the option of starting with a clean 
> slate it's not clear how much better we could do, and scrubbing the 
> internet's security posture down to the metal and starting over isn't 
> really an option. We have to work to improve the internet as we find it, 
> imperfections and tradeoffs and all.

How about HTTP/2 ?
Also a lot of smart minds completely ignored HTTP Digest Authentication for 
years, allowing Basic (plain text) password to be sent when login in on sites.

I hate plain text logins, how many blogs and forums out there have plain text 
logins right now? The number is scary I'm sure.
MITM attacks are one thing, what is worse are network eavesdropping, login to 
your blog or forum from a Cafe and you are screwed basically. IT has been shown 
that despite using WPA2 to the router, others on the same router can catch 
packets and decrypt them. And then they have your login/password.

Now when I make logins for web projects I use a Javascript client side based 
HMAC and a challenge-response so I do not even send the HMAC/hash over the 
network.

The server gives the javascript/client a challenge and a nonce, the password 
which the user knows and server knows (actually the server only knows a hmac of 
the pass and salt) is used with the challenge and then the result is sent back 
as a answer.
An eaves dropper will not be able to get the password.

Now, there are other attacks that could be used like session exploits but this 
is true even for HTTPS connections.

And a javascript/client solution like this is open to a MITTM attack since it's 
not encrypted or signed in any way (code signing certificates are even more 
expensive than site certificates).

I'd like to see a Client based HMAC Challenge-Responsive built in and a way for 
a browser and a serverside script to establish a encrypted connection without 
he need for certificates.
This would solve the plaintext login headache, and would be attractive to sites 
that only have HTTP (no HTTPS option) but has for example PHP support or some 
other scripting language.

HTTP/2 could be extended to improve the way HTTP Digest Authentication works, 
adding a HMAC(PSWD+SALT) + Challenge(NONCE) = Response(HASH) method.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: May I execute mozIStorageStatement.executeAsync() at the same time in a single thread?

[Yonggang Luo]

在 2015年4月25日星期六 UTC+8上午3:28:02，David Rajchenbach-Teller写道：
> By the way, I don't know if you're writing JS code or C++ code, but if
> it's the former, you really should use Sqlite.jsm.
Yes, I was using Javascript code, maybe that's was the cause of failure.
> 
> Cheers,
>  David
> 
> On 24/04/15 18:48, Yonggang Luo wrote:
> > I am currently using executeAsync to do async sqlite operation
> > in main thread, and running multiple executeAsync  in parallel, and it's 
> > crashed,
> > I am not so sure if multiple executeAsync can be executed at the same time.
> > ___
> > 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

Re: Intent to deprecate: Insecure HTTP

[Martin Thomson]

This is a digression, but it touches on an important question that
others are asking in response to this general push [1].

Fundamentally, better client authentication doesn't do anything to
help make the web a more secure place (in any of the dimensions that
we're primarily concerned about in this thread, anyway).  They can
actually make things worse by creating more ways of tracking users.

On Fri, Apr 24, 2015 at 3:28 PM, Roger Hågensen  wrote:
> How about HTTP/2 ?
> Also a lot of smart minds completely ignored HTTP Digest Authentication for 
> years, allowing Basic (plain text) password to be sent when login in on sites.

The problems with both digest and basic are primarily poor UX.  This
is well-known.  From a security perspective, both are pretty poor, but
since the UX was so poor they weren't used that much.  Consequently,
they were neglected.

HTTP APIs have been used more in recent years, so we're seeing more
demand for better mechanisms that are native to the protocol.  OAuth
is one such thing.  And new authentication methods are being developed
in the httpauth working group in the IETF [2].  Participation is open
there, feel free to sign up.  You can also look into essentially
proprietary systems like hawk [3], which Mozilla services have decided
they quite like.

> HTTP/2 could be extended to improve the way HTTP Digest Authentication works, 
> adding a HMAC(PSWD+SALT) + Challenge(NONCE) = Response(HASH) method.

HTTP/2 is not the place for authentication improvements.  We
specifically removed the mechanism Google invented for SPDY early in
the HTTP/2 process for that reason (and others).

The mechanisms cited above all work perfectly well with HTTP/1.1, and
that's still considered an important property.

[1] http://www.w3.org/DesignIssues/Security-ClientCerts.html
[2] https://tools.ietf.org/wg/httpauth
[3] https://github.com/hueniverse/hawk
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform