Re: Intent to ship: Hyperlink Auditing ()
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, making it somewhat clearer to the user what's going on. The text will still be difficult to understand but less obscure than the Google-vomit URLs you see now. Leaving the about:config pref in means that extensions can disable pings but probably not enough to drive people away from using the feature. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Hyperlink Auditing ()
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 covered by the preference. > > True, but those methods are being done outside of a browser feature we have > control over. In this case given that we can implement and control this > particular feature behavior we should try to implement it in a way that > aligns with our projects values. No, I don't think we can implement control over "this particular feature behavior", since for the user to actually have control, the description of the preference needs to be understandable and then actually do what it says. We can control one technical underpinning of tracking which links a user follows, but we can't control all of them. This means that any preference for this that we expose to users would either have to be described in technical jargon that's not meaningful to most users, would have to either be untruthful or unclear about what effects it has. Compare this to the preference for DNT, which says "Tell sites that I do not want to be tracked". [1] That's understandable, but also makes it clear that it's not preventing tracking but telling the other end about a preference. Supporting user control should mean that the choices we expose to users actually control useful and understandable things. -David [1] Speaking of DNT -- if it's all just the honor system for honoring this preference anyway -- why shouldn't it just be based on the DNT header anyway? We send the DNT header in the network request for the ping, right? -- š¯„˛ L. David Baron http://dbaron.org/ š¯„‚ š¯„¢ Mozilla https://www.mozilla.org/ š¯„‚ Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Hyperlink Auditing ()
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 is really "track via pings, or track via slower redirect". Sites can certainly tell if it's enabled with the help of a server (which those using it would have anyway); they can try it once, and if they get the ping, set a cookie. (And then they might use the faster ping method rather than the redirect only if the cookie is set.) -David -- š¯„˛ L. David Baron http://dbaron.org/ š¯„‚ š¯„¢ Mozilla https://www.mozilla.org/ š¯„‚ Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: navigator.hardwareConcurrency
> > 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 even implement this since the operating > systems don't give us such information. > > In the meantime, there are developers out there who are downloading > > micro-benchmarks on every client to stress-test the browser and determine > > the number of physical core. This is nonsense, we can all agree, but unless > > you give them a short-term alternative, they'll keep doing exactly that. > > And "native" will keep looking a lot more usable than the web. > > I agree. > Do you have pointers where people are describing this? I'm about to add a worker pool to Prototypo[1] and I'll have to use this script. Today it provides the most reliable source of info on how many jobs I can run concurrently. And it saddens me. [1] http://www.prototypo.io ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: navigator.hardwareConcurrency
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 confusion. Also I'm unsure how we could even implement this since the operating systems don't give us such information. > In the meantime, there are developers out there who are downloading > micro-benchmarks on every client to stress-test the browser and determine > the number of physical core. This is nonsense, we can all agree, but unless > you give them a short-term alternative, they'll keep doing exactly that. > And "native" will keep looking a lot more usable than the web. I agree. Do you have pointers where people are describing this? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: navigator.hardwareConcurrency
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 job is added to the queue or when a core becomes available jobHandler() { if ( isJobInTheQueue && isCoreAvailable ) { if ( noWorkerAvailable ) { pool.spawnWorker(); } pool.distribute( queue.pullJob() ); } } ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: navigator.hardwareConcurrency
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 stress-test the browser and determine the number of physical core. This is nonsense, we can all agree, but unless you give them a short-term alternative, they'll keep doing exactly that. And "native" will keep looking a lot more usable than the web. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Hyperlink Auditing ()
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 an "anti tracking" mode because that's extremely difficult-to-impossible to do robustly just on the client, and would be a misleading claim and/or result in a browser most people would think is broken. E.G. as already noted in this thread, sites can already do this without . Justin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Hyperlink Auditing ()
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 covered by the preference. > > Yes; but the methods being used by at (least some major) sites are > visible to the user, which makes them less insidious than an > invisible-by-design tracking feature. I doubt that the common user will notice any of these tracking measures. Even I wouldn't notice if I don't pay attention or the network would not sometimes be slow to load. > If we implement , and make it on-by-default (but with a user > preference to turn it off), we can reasonably expect sites to use this > as their tracking method in place of redirects, etc. And if they hten > detect (can they?) that the user has turned off pings and fall back to > other methods to track the user - who by disabling it has expressed a > desire not to be tracked - this puts them in much the same category as > those who decide to stop honoring Do Not Track. Web pages can't detect whether pings are actually sent, they know when those arrive at their endpoints. Thus if a website is concerned about Firefox users having turned this feature off they might just keep it the way it currently is and thus be sure it works for every user. > We can't force sites to honor DNT, and we can't prevent them working > around user-disabled . But in both cases we can and should (IMO) > provide a simple means for the user to express a wish about tracking. > Respectable sites will interoperate nicely with it; those that decide to > circumvent it should be publicly shamed. Using DNT is a flawed comparison, DNT is very much only about letting websites know without the ability to prevent any of that tracking. Websites can't tell whether is enabled and thus there is no real point in shaming any of them when we can't even prove they're not using because some users might have turned it off. - Tim ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Hyperlink Auditing ()
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 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 preference is exposed. We could also do something very innovative in this case like what is done with do not track. We could default to allowing all requests (which would honor the spec) but allow the users to change the pref to 2 other states. One being only allow pings from the sites I specify and the final one being donā€™t allow any at all. With accompanying text that explains the tradeoffs/benefits/pain of each setting. This would help us both keep inline with the goal of Hyperlink Auditing and balance our stance on privacy. [1] https://wiki.mozilla.org/Privacy/Principles -- Curtis ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform 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. Yes; but the methods being used by at (least some major) sites are visible to the user, which makes them less insidious than an invisible-by-design tracking feature. If we implement , and make it on-by-default (but with a user preference to turn it off), we can reasonably expect sites to use this as their tracking method in place of redirects, etc. And if they hten detect (can they?) that the user has turned off pings and fall back to other methods to track the user - who by disabling it has expressed a desire not to be tracked - this puts them in much the same category as those who decide to stop honoring Do Not Track. We can't force sites to honor DNT, and we can't prevent them working around user-disabled . But in both cases we can and should (IMO) provide a simple means for the user to express a wish about tracking. Respectable sites will interoperate nicely with it; those that decide to circumvent it should be publicly shamed. JK ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Hyperlink Auditing ()
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 that I can force single requests/channels into private mode, which means they won't persist cookies, sessionStorage, cache entries, etc. All other means of tracking navigation by rewriting links before clicking and then redirecting, or firing a sync XHR do still work and probably can't be disabled because they would break the web. - Tim ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Hyperlink Auditing ()
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 covered by the preference. > > True, but those methods are being done outside of a browser feature we have > control over. In this case given that we can implement and control this > particular feature behavior we should try to implement it in a way that > aligns with our projects values. Yes, but that might lead to non-use, which leads to worse performance for our users due to alternate methods deployed (and less obvious introspection of data flows through e.g. extensions). -- http://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Hyperlink Auditing ()
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 channels inherit the privacy status of the document that > created them, which means that they work correctly most of the time. However, > sometimes you need to adjust the privacy status on a channel manually, for > example, if you have created the channel directly yourself. You can use the > nsIPrivateBrowsingChannel interface for this purpose. The example below > creates a channel to load a URL, and forces it to be in private mode. > > var channel = Services.io.newChannel("http://example.org";, null, null); > > channel > .QueryInterface(Components.interfaces.nsIPrivateBrowsingChannel); > > channel > .setPrivate(true); // force the channel to be loaded in private mode > Similarly, XMLHttpRequest objects created via > createInstance(Ci.nsIXMLHttpRequest) will often require explicit adjustment, > since they have no context from which to derive a privacy status. > > var xhr = > Components.classes["@mozilla.org/xmlextras/xmlhttprequest;1"].createInstance(Components.interfaces.nsIXMLHttpReqeust); > var channel = > xhr.channel.QueryInterface(Components.interfaces.nsIPrivateBrowsingChannel); > > channel > .setPrivate(true); On 16 May, 2014, at 09:39 AM, Tim Taubert wrote: > 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 -- Curtis ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Hyperlink Auditing ()
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 done outside of a browser feature we have control over. In this case given that we can implement and control this particular feature behavior we should try to implement it in a way that aligns with our projects values. -- Curtis ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Hyperlink Auditing ()
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Hyperlink Auditing ()
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 > > *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 implementation follows > the spec but is disabled by default. If a website wants to audit > navigation to outgoing links (think Google, DuckDuckGo, Facebook, etc.) > it nowadays has to either link to an internal page to record and then > redirect to the target page or use sync XHRs. allows to > asynchronously (and with low prio) send one or multiple pings after or > while we start loading the target page. > > *Bug to enable by default* > https://bugzilla.mozilla.org/show_bug.cgi?id=951104 > > *Notes* > The navigator.sendBeacon() API is a superset of . > allows for lightweight navigation pings without having to use JavaScript. > > The number of pings per link is currently limited to 1 > (browser.send_pings.max_per_link). Chrome does not limit the number of > pings, we should look into raising or disabling the limit. > > > - Tim > > > -- > Tim Taubert > Engineering Manager, Firefox > @ttaubert > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform -- Curtis Koenig Mozilla Corp. Security Program Manager ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: 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 the preference is exposed. We > could also do something very innovative in this case like what is done with > do not track. We could default to allowing all requests (which would honor > the spec) but allow the users to change the pref to 2 other states. One being > only allow pings from the sites I specify and the final one being donā€™t allow > any at all. With accompanying text that explains the tradeoffs/benefits/pain > of each setting. This would help us both keep inline with the goal of > Hyperlink Auditing and balance our stance on privacy. I am all for "real choice" and keeping the user in control but offering these preferences does nothing but pretend to protect users and their privacy. If there is a chance the user might have turned it off without the site noticing then websites will just keep on doing what they do currently. Without any chance for the user to intervene or limit, and without a way to notice this is happening. And with all the current performance impacts. - Tim ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Hyperlink Auditing ()
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 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 preference is exposed. We > could also do something very innovative in this case like what is done with > do not track. We could default to allowing all requests (which would honor > the spec) but allow the users to change the pref to 2 other states. One being > only allow pings from the sites I specify and the final one being donā€™t allow > any at all. With accompanying text that explains the tradeoffs/benefits/pain > of each setting. This would help us both keep inline with the goal of > Hyperlink Auditing and balance our stance on privacy. > > [1] https://wiki.mozilla.org/Privacy/Principles > -- > Curtis > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform 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. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Hyperlink Auditing ()
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 preference would be a positive move. Davidā€™s point is more correct in that we need to be careful as to how the preference is exposed. We could also do something very innovative in this case like what is done with do not track. We could default to allowing all requests (which would honor the spec) but allow the users to change the pref to 2 other states. One being only allow pings from the sites I specify and the final one being donā€™t allow any at all. With accompanying text that explains the tradeoffs/benefits/pain of each setting. This would help us both keep inline with the goal of Hyperlink Auditing and balance our stance on privacy. [1] https://wiki.mozilla.org/Privacy/Principles -- Curtis ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Hyperlink Auditing ()
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 that sort of tracking in many other ways that aren't controlled > by the preference. That's a great point. I think it really might make sense to remove the preferences altogether as the number of pings per link limit and the same hosts requirement can actually be worked around quite easily and would make websites just fall back to the same bad behavior that we currently have. Ensuring this feature works as expected would surely drive adoption a lot better. - Tim ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Hyperlink Auditing ()
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 silent, or else the preference is really "track via pings, or track via slower redirect". On 2014-05-16 08:35, Jonathan Kew wrote: > 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 >>> used to track me. >> >> You actually don't, since Google doesn't add the tracking stuff to >> the link until you click it. But it adds it early enough in click >> handling so that it affects what happens when you click the link. >> >> To see this: >> 1. search for something on Google >> 2. hover over the link in a result; you see a normal link >> 3. right-click to get the link's context menu >> 4. hover over the link again >> >> In step (2) you see the link on its own; in step (4) you see the >> version with the tracking redirect added. > > Yes; but even if I simply click the link at step (2), I see (via the > status overlay) that it actually sends me via a Google tracking URL > instead of directly to the destination. I remember noticing (and > disapproving) when this behavior was first introduced to their search > results. > > At that point, of course, it's too late to decide I didn't want Google > to know that I clicked that link -- but in the process, I've learned > something: that Google search results are not simply links for my > browser to follow, but "booby-traps" that will report back to Google > before taking me to the target page. And if I don't like that, I might > decide to look for a different search engine, or to be more careful what > I do with results in future. > > Replacing the redirects with will completely hide this from me; > in that case, I might never have noticed that clicking those links was > anything more than a simple "go to this page". > > 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? > > For comparison, I really like the fact that when an email comes with > return receipt request, Thunderbird will ask me something like "the > sender asked to be notified when you open this message..." and let me > choose whether or not to respond. While I guess will probably > become so widespread that I wouldn't want to be prompted every time > ("Google asked to be notified when you click this link..."), some kind > of user notification and UI to opt in/out of tracking does seem needed here. > > JK > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Hyperlink Auditing ()
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 there, though. If enough users opt out of the preference for sites to care, then sites will just use other ways to track users that aren't controlled by the preference. (And sites could certainly use other ways that don't show up in the "Loading..." message in the status bar as well; some of these would probably also be faster than redirects.) 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 that sort of tracking in many other ways that aren't controlled by the preference. -David -- š¯„˛ L. David Baron http://dbaron.org/ š¯„‚ š¯„¢ Mozilla https://www.mozilla.org/ š¯„‚ Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Hyperlink Auditing ()
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 used to track me. You actually don't, since Google doesn't add the tracking stuff to the link until you click it. But it adds it early enough in click handling so that it affects what happens when you click the link. To see this: 1. search for something on Google 2. hover over the link in a result; you see a normal link 3. right-click to get the link's context menu 4. hover over the link again In step (2) you see the link on its own; in step (4) you see the version with the tracking redirect added. Yes; but even if I simply click the link at step (2), I see (via the status overlay) that it actually sends me via a Google tracking URL instead of directly to the destination. I remember noticing (and disapproving) when this behavior was first introduced to their search results. At that point, of course, it's too late to decide I didn't want Google to know that I clicked that link -- but in the process, I've learned something: that Google search results are not simply links for my browser to follow, but "booby-traps" that will report back to Google before taking me to the target page. And if I don't like that, I might decide to look for a different search engine, or to be more careful what I do with results in future. Replacing the redirects with will completely hide this from me; in that case, I might never have noticed that clicking those links was anything more than a simple "go to this page". 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? For comparison, I really like the fact that when an email comes with return receipt request, Thunderbird will ask me something like "the sender asked to be notified when you open this message..." and let me choose whether or not to respond. While I guess will probably become so widespread that I wouldn't want to be prompted every time ("Google asked to be notified when you click this link..."), some kind of user notification and UI to opt in/out of tracking does seem needed here. JK ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
HTTP cache v2 now enabled "for real" on mozilla-inbound
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 one very low volume and hard to reproduce bug: 998608 - test_range_requests.js | request reports itself as not pending from onDataAvailable! I'm currently working on fixing it. -hb- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Hyperlink Auditing ()
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 a clue that > the site is doing something more than simply giving me a link that I > follow, and if I want to avoid telling Google which results I'm > clicking, I need to somehow work around this. Google and DuckDuckGo are hiding these, when hovering a search result link I don't see that the browser will request a different page first and redirect me afterwards. I think for the average user this is hardly different from not seeing any hint at all. > If this is replaced by the use of on those search results, then > (AFAICT) there will no longer be *any* clue to alert me as a user to the > fact that the site is monitoring which result I click on. This allows > pages to more easily track me without ever bringing it to my attention. > So I do think there's a disadvantage here. The argument "we make it easier to track" seems valid at first but we can't even prevent that right now. If sites want to and will do that anyway we should at least provide a way that has less disadvantages for the user. - Tim -- Tim Taubert Engineering Manager, Firefox @ttaubert ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Hyperlink Auditing ()
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, since Google doesn't add the tracking stuff to the link until you click it. But it adds it early enough in click handling so that it affects what happens when you click the link. To see this: 1. search for something on Google 2. hover over the link in a result; you see a normal link 3. right-click to get the link's context menu 4. hover over the link again In step (2) you see the link on its own; in step (4) you see the version with the tracking redirect added. -David -- š¯„˛ L. David Baron http://dbaron.org/ š¯„‚ š¯„¢ Mozilla https://www.mozilla.org/ š¯„‚ Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Hyperlink Auditing ()
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 hardly an optimal UI, at least I get a clue that the > site is doing something more than simply giving me a link that I follow, and > if I want to avoid telling Google which results I'm clicking, I need to > somehow work around this. > > If this is replaced by the use of on those search results, then > (AFAICT) there will no longer be *any* clue to alert me as a user to the > fact that the site is monitoring which result I click on. This allows pages > to more easily track me without ever bringing it to my attention. So I do > think there's a disadvantage here. I suspect that most end users do not realize this and probably wonder more why things are slower in Firefox (assuming that browsers that ping get to the target page directly). There's also nothing preventing us from exposing the ping attribute in some way, though probably extensions need to lead the way there. -- http://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Hyperlink Auditing ()
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 >> the user from my POV here. > > It should be better as closing a document is no longer halted by > synchronous XMLHttpRequest. Are we implementing them in such a way > they can be transmitted even if the window goes away? So performance > for the user is optimal and developers don't feel forced to slow > things down? Yes, is implemented only to ping when the user clicks a link and navigates away from the current document. Thus transmitting the ping when the inner window goes away is a requirement. The outer window going away isn't a problem either because we create independent http channels/requests that will be held alive by the networking subsystem until they succeed or time out. - Tim -- Tim Taubert Engineering Manager, Firefox @ttaubert ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Hyperlink Auditing ()
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 altogether, or selectively ignore URLs in the list (e.g. ignoring any third-party URLs)." Users can disable sendings pings by flipping a preference. They can limit the number of pings sent per link. They can restrict pings to the same host as the document in which the click occurs by flipping a pref. "When the ping attribute is present, user agents should clearly indicate to the user that following the hyperlink will also cause secondary requests to be sent in the background, possibly including listing the actual target URLs." This is covered by bug 401352. ...which has seen no apparent activity since it was filed, over 6 years ago. :( What's our story here? It's not obvious to me from a (brief) look at the bugs whether we have addressed these issues. Without them, I find the idea of quite disturbing... We don't have a story here at the moment. Sites currently audit external navigation by using redirects and sync XHRs which don't notify the user either but at the same time make navigation a lot slower. 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. 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 a clue that the site is doing something more than simply giving me a link that I follow, and if I want to avoid telling Google which results I'm clicking, I need to somehow work around this. If this is replaced by the use of on those search results, then (AFAICT) there will no longer be *any* clue to alert me as a user to the fact that the site is monitoring which result I click on. This allows pages to more easily track me without ever bringing it to my attention. So I do think there's a disadvantage here. JK ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Hyperlink Auditing ()
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 should be better as closing a document is no longer halted by synchronous XMLHttpRequest. Are we implementing them in such a way they can be transmitted even if the window goes away? So performance for the user is optimal and developers don't feel forced to slow things down? -- http://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Hyperlink Auditing ()
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 in the list > (e.g. ignoring any third-party URLs)." Users can disable sendings pings by flipping a preference. They can limit the number of pings sent per link. They can restrict pings to the same host as the document in which the click occurs by flipping a pref. > "When the ping attribute is present, user agents should clearly indicate > to the user that following the hyperlink will also cause secondary > requests to be sent in the background, possibly including listing the > actual target URLs." This is covered by bug 401352. > What's our story here? It's not obvious to me from a (brief) look at the > bugs whether we have addressed these issues. Without them, I find the > idea of quite disturbing... We don't have a story here at the moment. Sites currently audit external navigation by using redirects and sync XHRs which don't notify the user either but at the same time make navigation a lot slower. 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. - Tim >> *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 implementation follows >> the spec but is disabled by default. If a website wants to audit >> navigation to outgoing links (think Google, DuckDuckGo, Facebook, etc.) >> it nowadays has to either link to an internal page to record and then >> redirect to the target page or use sync XHRs. allows to >> asynchronously (and with low prio) send one or multiple pings after or >> while we start loading the target page. >> >> *Bug to enable by default* >> https://bugzilla.mozilla.org/show_bug.cgi?id=951104 >> >> *Notes* >> The navigator.sendBeacon() API is a superset of . >> allows for lightweight navigation pings without having to use JavaScript. >> >> The number of pings per link is currently limited to 1 >> (browser.send_pings.max_per_link). Chrome does not limit the number of >> pings, we should look into raising or disabling the limit. >> >> >> - Tim >> >> > -- Tim Taubert Engineering Manager, Firefox @ttaubert ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [Sheriffs] UPDATE: Current action plan for try server issues
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 help so far! Best wishes, Ed On 15 May 2014 22:36:01, Hal Wine wrote: Thanks to a few hours of debugging by glandium Tuesday night, a tweak has been made which may address the multi-hour delays we had been seeing. (As of now, we've seen one successful push that took ~38 min of CPU and wall clock time to complete.) With that in place, the current plans are: a) right now we're monitoring for the impact (if any) of changes outlined in bug 1001735 comment 39 b) if there are any significant issues, we will perform a new history-preserving reset of try c) if there continue to be any significant issues, we will fall back to the old try reset which deletes history We have some confidence that (b) will be successful, and could be automated with minimal try closure time. I'll get a new bug open on that within a few days. --Hal On 2014-05-01, 11:26 , Hal Wine wrote: [including dev.platform this time as originally intended] tl;dr: there was a 4h "outage" on Wed, here's our plan if it happens again. Active bug for next reset: bug 1001735 (https://bugzil.la/1001735) Action Summary: - if we get another multi-hour (>2) "outage", we will immediately do a hard reset of try during business hours. - in parallel, we are looking at several "history preserving" methods for try resets - we will announce any hard reset here, along with the status of history. - we will announce any updates to this plan here Details: - many devs had timeouts on push to try - nothing landed on try for a 4h period, between Wed Apr 30 18:55:32 2014 + & Wed Apr 30 23:05:24 2014 + - try has been responsive since then. Please let me know if anyone has strong objections to the above. --Hal ___ Sheriffs mailing list sheri...@mozilla.org https://mail.mozilla.org/listinfo/sheriffs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Hyperlink Auditing ()
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 Referer (sic) headers. Based on the user's preferences, UAs may either ignore the ping attribute altogether, or selectively ignore URLs in the list (e.g. ignoring any third-party URLs)." "When the ping attribute is present, user agents should clearly indicate to the user that following the hyperlink will also cause secondary requests to be sent in the background, possibly including listing the actual target URLs." What's our story here? It's not obvious to me from a (brief) look at the bugs whether we have addressed these issues. Without them, I find the idea of quite disturbing... JK *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 implementation follows the spec but is disabled by default. If a website wants to audit navigation to outgoing links (think Google, DuckDuckGo, Facebook, etc.) it nowadays has to either link to an internal page to record and then redirect to the target page or use sync XHRs. allows to asynchronously (and with low prio) send one or multiple pings after or while we start loading the target page. *Bug to enable by default* https://bugzilla.mozilla.org/show_bug.cgi?id=951104 *Notes* The navigator.sendBeacon() API is a superset of . allows for lightweight navigation pings without having to use JavaScript. The number of pings per link is currently limited to 1 (browser.send_pings.max_per_link). Chrome does not limit the number of pings, we should look into raising or disabling the limit. - Tim ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: Hyperlink Auditing ()
*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 implementation follows the spec but is disabled by default. If a website wants to audit navigation to outgoing links (think Google, DuckDuckGo, Facebook, etc.) it nowadays has to either link to an internal page to record and then redirect to the target page or use sync XHRs. allows to asynchronously (and with low prio) send one or multiple pings after or while we start loading the target page. *Bug to enable by default* https://bugzilla.mozilla.org/show_bug.cgi?id=951104 *Notes* The navigator.sendBeacon() API is a superset of . allows for lightweight navigation pings without having to use JavaScript. The number of pings per link is currently limited to 1 (browser.send_pings.max_per_link). Chrome does not limit the number of pings, we should look into raising or disabling the limit. - Tim -- Tim Taubert Engineering Manager, Firefox @ttaubert ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform