I concur. 1 in every 12 loads require an HTTP auth prompt? Seems very high.
Visual inspection of the probe implementations [1] [2] show no obvious
faults, so I'm not sure what's going on here.
[1]
https://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsHttpChannelAuthProvider.cpp#78
Is there a way that we can gather if people are using this for testing web
sites? This might account for those numbers.
For example, there is basic support, and I mean really basic support, in
Selenium to handle Basic auth and we suggest to people that setting up a
proxy in the middle to handle th
On 11/06/2016 03:27, Jason Duell wrote:
This data also smells weird to me. 8% of pages using basic auth seems very
very high, and only 0.7% of basic auth being done unencypted seems low.
Nitpick: it's 0.7% of total traffic - 749k / 8.7 million ~> 8.6% of
basic auth is over unencrypted connect
This data also smells weird to me. 8% of pages using basic auth seems very
very high, and only 0.7% of basic auth being done unencypted seems low.
Perhaps we should chat in London (ideally with Honza Bambas) and make sure
we're getting the telemetry right here.
Jason
On Fri, Jun 10, 2016 at 2:1
On 4/18/16 09:59, Richard Barnes wrote:
Could we just disable HTTP auth for connections not protected with TLS? At
least Basic auth is manifestly insecure over an insecure transport. I
don't have any usage statistics, but I suspect it's pretty low compared to
form-based auth.
As a follow up f
On 4/19/16 1:58 AM, Panos Astithas wrote:
Why should we be the ones to take the web compat hit on this?
>
> is the fundamentally biggest issue.
>
I realize I'm late to this thread and the discussion has moved the original
proposal towards something more refined and hence more likely to succeed,
On Fri, Apr 15, 2016 at 5:47 PM, Tantek Çelik
wrote:
> However, As EKR pointed out, Kyle Huey's
>
> > Why should we be the ones to take the web compat hit on this?
>
> is the fundamentally biggest issue.
>
I realize I'm late to this thread and the discussion has moved the original
proposal towar
On 2016-04-18 7:59 AM, Richard Barnes wrote:
Could we just disable HTTP auth for connections not protected with TLS? At
least Basic auth is manifestly insecure over an insecure transport. I
don't have any usage statistics, but I suspect it's pretty low compared to
form-based auth.
I also don'
On Fri, Apr 15, 2016 at 5:45 PM, Matthew N. wrote:
> On 2016-04-15 7:47 AM, Tantek Çelik wrote:
>
>> What steps can we take in this direction WITHOUT breaking web compat?
>>
>>
>> E.g. since one of the issues raised is that *every* time a user
>> enters/submits a password over HTTP (not secure),
On 4/15/16 2:12 AM, Jason Duell wrote:
> Focusing on third-party session cookies is an interesting idea.
> "Sessionizing" non-HTTPS third-party cookies would encourage ad networks
> and CDNs to use HTTPS, allowing content sites to use HTTPS without mixed
> content problems. Much later, we could c
On 17 Apr 2016 2:37 AM, "Haik Aftandilian" wrote:
>
> Sites might depend on a combination of https and non-https cookies and
then
> act strangely when a user returns to the site with only the https cookies.
This is also known as a security vulnerability. See
https://www.usenix.org/conference/usen
On Fri, Apr 15, 2016 at 7:37 PM, Chris Peterson
wrote:
> On 4/15/16 7:47 AM, Tantek Çelik wrote:
>
>> What steps can we take in this direction WITHOUT breaking web compat?
>>
>
> Would this feature actually break web compatibility? Or just needlessly
> annoy users?
>
> In his original post, Henri
On 4/15/16 11:37 PM, Chris Peterson wrote:
On 4/15/16 7:47 AM, Tantek Çelik wrote:
What steps can we take in this direction WITHOUT breaking web compat?
Would this feature actually break web compatibility? Or just needlessly
annoy users?
I think this is one of the fuzzy browser UX/sec/perf i
On 4/15/16 7:47 AM, Tantek Çelik wrote:
What steps can we take in this direction WITHOUT breaking web compat?
Would this feature actually break web compatibility? Or just needlessly
annoy users?
In his original post, Henri argued that clearing non-HTTPS cookies
between sessions would not "B
On 2016-04-15 7:47 AM, Tantek Çelik wrote:
What steps can we take in this direction WITHOUT breaking web compat?
E.g. since one of the issues raised is that *every* time a user
enters/submits a password over HTTP (not secure), it opens them to
being sniffed etc., thus it's good to discourage th
On Thu, Apr 14, 2016 at 10:54 PM, Chris Peterson wrote:
> Thanks for all the feedbck. I anticipated this proposal might not be
> practical with real world sites, so it's better to halt it here. :) I should
> have framed this email as an RFC instead of an intent to ship.
>
Thanks Chris for bringin
On Fri, Apr 15, 2016 at 2:12 AM, Jason Duell wrote:
> On Thu, Apr 14, 2016 at 10:54 PM, Chris Peterson
> wrote:
>
>>
>> Focusing on third-party session cookies is an interesting idea.
>> "Sessionizing" non-HTTPS third-party cookies would encourage ad networks
>> and CDNs to use HTTPS, allowing c
On Thu, Apr 14, 2016 at 10:54 PM, Chris Peterson
wrote:
>
> Focusing on third-party session cookies is an interesting idea.
> "Sessionizing" non-HTTPS third-party cookies would encourage ad networks
> and CDNs to use HTTPS, allowing content sites to use HTTPS without mixed
> content problems. Muc
On 15/04/16 03:58 AM, Tanvi Vyas wrote:
> So how about a preference that treats all cookies set in a third party
> context as session cookies. We could restrict this to HTTP, or even
> apply it to third party HTTPS cookies.
We seem to have this already: network.cookie.thirdparty.sessionOnly
Fran
Thanks for all the feedbck. I anticipated this proposal might not be
practical with real world sites, so it's better to halt it here. :) I
should have framed this email as an RFC instead of an intent to ship.
Focusing on third-party session cookies is an interesting idea.
"Sessionizing" non-HT
Chris,
Le 14 avr. 2016 à 17:54, Chris Peterson a écrit :
> Instead, I propose treating all cookies set over non-secure HTTP as session
> cookies, regardless of whether they have the `secure` flag. […] To test my
> proposal, I loaded the home pages of the Alexa Top 25 News sites [2].
To test th
The restriction to third-party requests is an interesting suggestion
and might provide some of the benefits Chris mentioned in the original
proposal. Seems like a change done carefully and with others. best,
Joe
On Thu, Apr 14, 2016 at 4:32 PM, Martin Thomson wrote:
> I would like to see other br
I would like to see other browsers on board before taking on these risks.
And a lot more testing.
For instance, is there a way to collect telemetry on the impact of
such a change without actually implementing it? Does restricting it
to 3rd party requests change things?
On Fri, Apr 15, 2016 at 1
On the surface, this seems like a great idea and privacy win - it gets
rid of all those pesky tracking cookies! But under the covers there are
a lot of issues, as mentioned by previous replies and summarized below:
* Puts the user's password at greater risk, since the user has to enter
it and
On Thu, Apr 14, 2016 at 1:54 AM, Chris Peterson
wrote:
> Summary: Treat cookies set over non-secure HTTP as session cookies
>
> Exactly one year ago today (!), Henri Sivonen proposed [1] treating
> cookies without the `secure` flag as session cookies.
>
> PROS:
>
> * Security: login cookies set o
This seems like the right question.
-Ekr
On Thu, Apr 14, 2016 at 9:17 AM, Kyle Huey wrote:
> Why should we be the ones to take the web compat hit on this?
>
> - Kyle
> On Apr 14, 2016 1:55 AM, "Chris Peterson" wrote:
>
> > Summary: Treat cookies set over non-secure HTTP as session cookies
> >
I have two concerns with this.
First off, it means that users might need to actively log in to
websites more often. This is a really big hassle for users, especially
on mobile. We did some studies when we did FirefoxOS between the
differences between native versions and web version of various apps
Why should we be the ones to take the web compat hit on this?
- Kyle
On Apr 14, 2016 1:55 AM, "Chris Peterson" wrote:
> Summary: Treat cookies set over non-secure HTTP as session cookies
>
> Exactly one year ago today (!), Henri Sivonen proposed [1] treating
> cookies without the `secure` flag a
I don't see how we can do this by default without harming our users. We can
be confident that this will break persistent login for lots of sites. I
appreciate the goal of moving HTTPS forward, but we are not in a position
where we our marketshare would force changes to the web ecosystem.
Before tu
On Thu, Apr 14, 2016 at 11:54 AM, Chris Peterson wrote:
> * Sites that allow users to configure preferences without logging into an
> account would forget the users' preferences if they are not using HTTPS. For
> example, companies that have regional sites would forget the user's selected
> region
On Thu, Apr 14, 2016 at 6:54 PM, Chris Peterson
wrote:
>
> Do other browser engines implement this? No
>
I have no particular thought about the idea itself, but it seems to me this
is a breaking change to the web.
As it's a major breaking change, I don't think we should do this without
support
31 matches
Mail list logo
