On 16/5/14 10:29, Tim Taubert wrote:
*Link to Standard*
http://www.whatwg.org/specs/web-apps/current-work/#hyperlink-auditing
A couple of quotes from there:
User agents should allow the user to adjust this behavior, for example
in conjunction with a setting that disables the sending of HTTP
On Fri, May 16, 2014 at 1:49 PM, Jonathan Kew jfkth...@gmail.com 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
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
Hi all,
yesterday we have landed a patch that switches the pref to use the new
HTTP cache (bug 913806). It is enabled for all infra tests, talos and
Nightly users.
In case of any catastrophic problems it's easy to switch back (nothing
more then flipping the pref back). So far we know
On 16/5/14 13:02, L. David Baron wrote:
On Friday 2014-05-16 12:49 +0100, 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
On Friday 2014-05-16 13:35 +0100, Jonathan Kew wrote:
Maybe that's OK, but I do think this changes things in a significant
way, and we should give some priority to addressing the concerns.
Maybe the send-ping preference should be exposed at a similar level
to Do Not Track?
There's a tradeoff
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
On Fri, May 16, 2014 at 6:30 AM, Curtis Koenig curt...@mozilla.com wrote:
On 16 May, 2014, at 09:11 AM, Tim Taubert ttaub...@mozilla.com wrote:
I think it really might make sense to remove the
preferences altogether
Given our stance on privacy[1] and commitment to Real Choices, Sensible
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
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.
On 16 May, 2014, at 05:29 AM, Tim Taubert ttaub...@mozilla.com wrote:
*Link to Standard*
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
___
On 16 May, 2014, at 09:37 AM, Kyle Huey m...@kylehuey.com wrote:
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.
True, but those
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.
Forcing a channel into private mode
Usually, network
On Fri, May 16, 2014 at 3:40 PM, Curtis Koenig curt...@mozilla.com wrote:
On 16 May, 2014, at 09:37 AM, Kyle Huey m...@kylehuey.com wrote:
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
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
On 16/5/14 14:37, Kyle Huey wrote:
On Fri, May 16, 2014 at 6:30 AM, Curtis Koenig curt...@mozilla.com wrote:
On 16 May, 2014, at 09:11 AM, Tim Taubert ttaub...@mozilla.com wrote:
I think it really might make sense to remove the
preferences altogether
Given our stance on privacy[1] and
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
On 5/16/14, 6:38 AM, 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.
Private Browsing mode is about not storing _local_ data from your
activities. It is explicitly not
Do you think it would be feasible that the browser fires events every time the
number of cores available for a job changes? That might allow to build an
efficient event-based worker pool.
In the meantime, there are developers out there who are downloading
micro-benchmarks on every client to
Here's the naive worker pool implementation I was thinking about. It requires
that the browser fires an event everytime a core becomes available (only in an
active tab of course), and provide a property that tells whether or not a core
is available at a given time:
// a handler that runs when
On Fri, May 16, 2014 at 11:03 AM, lrb...@gmail.com wrote:
Do you think it would be feasible that the browser fires events every time
the number of cores available for a job changes? That might allow to build
an efficient event-based worker pool.
I think this will be very noisy and might
Do you think it would be feasible that the browser fires events every time
the number of cores available for a job changes? That might allow to build
an efficient event-based worker pool.
I think this will be very noisy and might cause a lot of confusion.
Also I'm unsure how we could
On Friday 2014-05-16 08:58 -0400, Wesley Hardman wrote:
Can you detect if a ping is enabled? If so, having a preference isn't
going to be particularly useful as sites will just fallback to the redirect
method. If it is added as a UI preference, it needs to be silent, or else
the
On Friday 2014-05-16 09:40 -0400, Curtis Koenig wrote:
On 16 May, 2014, at 09:37 AM, Kyle Huey m...@kylehuey.com wrote:
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
Seems to me we should indicate pings in the link status text (bug 401352),
indicate pinging in the status text while we load the next page, and retain
the about:config pref to disable pinging.
The first two measures seem low-cost and constitute a strict improvement on
the current privacy
25 matches
Mail list logo
