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 situation
On Friday 2014-05-16 09:40 -0400, Curtis Koenig wrote:
> On 16 May, 2014, at 09:37 AM, Kyle Huey 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
On Friday 2014-05-16 08:58 -0400, Wesley Hardman wrote:
> Can you detect if 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 preference i
> > 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 c
On Fri, May 16, 2014 at 11:03 AM, 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 cause a lot of co
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 a
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 str
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 a
Jonathan Kew wrote:
> On 16/5/14 14:37, Kyle Huey wrote:
>> On Fri, May 16, 2014 at 6:30 AM, Curtis Koenig
>> 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
On 16/5/14 14:37, Kyle Huey wrote:
On Fri, May 16, 2014 at 6:30 AM, Curtis Koenig wrote:
On 16 May, 2014, at 09:11 AM, Tim Taubert 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
Setti
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
On Fri, May 16, 2014 at 3:40 PM, Curtis Koenig wrote:
> On 16 May, 2014, at 09:37 AM, Kyle Huey 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 cov
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 16 May, 2014, at 09:37 AM, Kyle Huey 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 methods are being
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
___
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 wrote:
> *Link to Standard*
> http://www.whatwg.org/specs/web-apps/current-work/#hyperlink-auditing
>
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 th
On Fri, May 16, 2014 at 6:30 AM, Curtis Koenig wrote:
>
> On 16 May, 2014, at 09:11 AM, Tim Taubert 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
> Settings and User Control; I
On 16 May, 2014, at 09:11 AM, Tim Taubert 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
Settings and User Control; I don’t believe removing the users ability to
control this preferenc
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
>
I just use "Remove Google Redirection" for Greasemonkey, so I don't have the
redirects.
Can you detect if 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 silen
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 tradeo
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
use
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 about
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 g
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
> used to track me.
You actually don't,
On Fri, May 16, 2014 at 1:49 PM, 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
Anne van Kesteren wrote:
> On Fri, May 16, 2014 at 12:20 PM, Tim Taubert wrote:
>> Calling the whole idea of "disturbing" makes it sound like we
>> would introduce a whole new concept, we just provide a saner way to do
>> things that lots of web pages want. There is no obvious disadvantage to
>>
On 16/5/14 11:20, Tim Taubert wrote:
Jonathan Kew wrote:
"User agents should allow the user to adjust this behavior, for example
in conjunction with a setting that disables the sending of HTTP Referer
(sic) headers. Based on the user's preferences, UAs may either ignore
the ping attribute altoge
On Fri, May 16, 2014 at 12:20 PM, Tim Taubert wrote:
> Calling the whole idea of "disturbing" makes it sound like we
> would introduce a whole new concept, we just provide a saner way to do
> things that lots of web pages want. There is no obvious disadvantage to
> the user from my POV here.
It
Jonathan Kew wrote:
> "User agents should allow the user to adjust this behavior, for example
> in conjunction with a setting that disables the sending of HTTP Referer
> (sic) headers. Based on the user's preferences, UAs may either ignore
> the ping attribute altogether, or selectively ignore URLs
Please could we look into updating hg.mozilla.org to a newer Mercurial
as well? (a la bug 945383)
It seems that many of the suggestions made across the various try
issues threads are dependant on newer Hg - and the perf improvements in
newer releases alone will help :-)
Many thanks for your he
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
*Link to Standard*
http://www.whatwg.org/specs/web-apps/current-work/#hyperlink-auditing
*Summary*
Anchor tags can have a "ping" attribute that sends asynchronous pings
after or while navigating to the target page for auditing purposes.
*Motivation*
Since bug 786347 landed our Hyperlink Auditing
34 matches
Mail list logo
