Author Topic: Blog: Firefox 22 Miscellaneous Stuff  (Read 226 times)

Offline menotu

  • PCLinuxOS Tester
  • Super Villain
  • *******
  • Posts: 15321
  • ┌∩┐(◕_◕)┌∩┐
Blog: Firefox 22 Miscellaneous Stuff
« on: February 24, 2013, 07:40:42 AM »
Firefox 22 release is scheduled for 24-Jun-2013

=============================

By Jonathan Mayer - 22-Feb- 2013

The New Firefox Cookie Policy   ([i]will block third-party cookies[/i])

The default Firefox cookie policy will, beginning with release 22, more closely reflect user privacy preferences. This mini-FAQ addresses some of the questions that I’ve received from Mozillans, web developers, and users.

How does the new Firefox cookie policy work?

Roughly: Only websites that you actually visit can use cookies to track you across the web.

More precisely: If content has a first-party origin,1 nothing changes. Content from a third-party origin only has cookie permissions if its origin already has at least one cookie set.
How does Firefox’s new policy compare to the other major browsers?

Chrome – Allows all cookies.

Internet Explorer – Cookie permissions vary by P3P compact policy. In practice, almost all third-party tracking cookies are allowed.

Safari – First-party content has cookie permissions. Third-party content only has cookie permissions if the content already has at least one cookie set.

Firefox - In short, the new Firefox policy is a slightly relaxed version of the Safari policy

Will the new Firefox policy break websites?

Collateral impact should be limited. Safari’s cookie policy has been in place for over a decade, and it is included in both the desktop and iOS versions of the browser. A few websites may require a tiny code change to accommodate Firefox in the same way as Safari.

Just to be sure, the Mozilla privacy team is closely monitoring the policy before final release. The patch will spend about 6 weeks each in the pre-alpha, alpha, and beta builds. If you spot any oddities, please report them to Mozilla support!

How can I test whether my website has cookie permissions?

Easy: try to set a cookie. This approach can introduce cookie permissions into both server-side and client-side code.

Browser sniffing is generally disfavored since it can be unreliable and requires updating. Moreover, sniffing will not accommodate Chrome and Internet Explorer users who have switched from the default cookie policy.

I operate a third-party website that uses cookies. What should I do?

If a Firefox user appears to have intentionally interacted with your content, take the same approach as for Safari users.4 Examples of content within this category include Facebook apps and comment widgets where a user has typed text.

If a user does not seem to have intentionally interacted with your content, or if you’re uncertain, you should ask for permission before setting cookies. Most analytics services, advertising networks, and unclicked social widgets would come within this category.

In sum, working around the policy’s technical limits may be reasonable in certain cases, but undermining the policy’s privacy purpose is never acceptable.

What happens to preexisting cookies?

The new policy does not make any special provision for preexisting cookies. Current Firefox users should clear their cookies to fully benefit from the new policy.5
What comes next for the Firefox cookie policy?

There’s still plenty of work to do. Some possible directions that I’m interested in:

    Extending the cookie policy to other storage technologies (e.g. HTML5 Web Storage).
    Providing a uniform mechanism for requesting storage permissions.
    Relaxing the cookie policy for websites that honor Do Not Track.

http://webpolicy.org/2013/02/22/the-new-firefox-cookie-policy/#firefox-cookie-policy-fnref:1

All views are solely my own. I (Jonathan Mayer)  do not speak for Mozilla.


Bug 818340 - Summary: Block cookies from sites I haven't visited

https://bugzilla.mozilla.org/show_bug.cgi?id=818340
« Last Edit: May 20, 2013, 08:07:26 AM by menotu »
PCLinuxOS 32bit KDE 4.10.1; kernel-3.4.11-pclos1.bfs & 64bit 3.2.18bfs; NVidia GeForce 8400GS 1GB 310.19 driver

Sony Vaio SVE1513A4ESI Laptop, Intel Core i5, 2.6GHz, 6GB RAM, 750GB, 15.6" Intel HD Graphics 4000

Offline menotu

  • PCLinuxOS Tester
  • Super Villain
  • *******
  • Posts: 15321
  • ┌∩┐(◕_◕)┌∩┐
Blog: Firefox 22 Miscellaneous Stuff
« Reply #1 on: April 08, 2013, 06:15:59 AM »
By Gregg Keizer - April 7, 2013 - Computerworld

Mozilla pulls tracking trigger for Firefox 22, ignores ad industry attacks

Adds auto-blocking of third-party cookies to 'Aurora' preview

Mozilla has added automatic third-party cookie-blocking to a preview version of Firefox 22, a move that will put the feature in most users hands by late June and the company on a collision course with the online ad industry.

Advertising trade groups have blasted the new cookie blocking, calling it "dangerous and highly disturbing," and promising that Firefox users would see more online ads as a result.

On Friday, the privacy advocate who created the blocking code said it had landed on the "Aurora" build channel. "The new Firefox cookie policy has migrated to Aurora!" tweeted Jonathan Mayer, a graduate student in computer science and law at Stanford University.

Mayer is also one of two Stanford researchers who created the HTTP header implementation that signals a user's "No Dot Track" privacy preference.

Aurora is the name for Firefox's least-polished preliminary version that is aimed at general users. In the open-source company's development cycle, Aurora is followed by Beta and then Release. Each edition of Firefox goes through the Aurora-Beta-Release cycles, spending six weeks each in the first two.

Firefox 22, slated to ship as Release on June 25, was moved on Friday to the Aurora channel. Mozilla listed the cookie blocking in its summary of  new features for the upcoming browser.   

https://www.computerworld.com/s/article/9238208/Mozilla_pulls_tracking_trigger_for_Firefox_22_ignores_ad_industry_attacks?source=rss_keyword_gregg+keizer
« Last Edit: May 20, 2013, 08:07:44 AM by menotu »
PCLinuxOS 32bit KDE 4.10.1; kernel-3.4.11-pclos1.bfs & 64bit 3.2.18bfs; NVidia GeForce 8400GS 1GB 310.19 driver

Sony Vaio SVE1513A4ESI Laptop, Intel Core i5, 2.6GHz, 6GB RAM, 750GB, 15.6" Intel HD Graphics 4000

Offline menotu

  • PCLinuxOS Tester
  • Super Villain
  • *******
  • Posts: 15321
  • ┌∩┐(◕_◕)┌∩┐
Blog: Firefox 22 Miscellaneous Stuff
« Reply #2 on: May 18, 2013, 05:17:42 AM »
By Brendan Eich (creator of JavaScript) and CTO of Mozilla - 16 May 2013

C is for Cookie

Mozilla is engaged in a broad, deep conversation about Internet privacy. We believe in putting users in control of their online experience, and we want a healthy, thriving web ecosystem — we do not see a contradiction. However, sometimes a crucial experiment is required to prove it.

To this end, we are testing a patch from Jonathan Mayer. Jonathan’s https://bugzilla.mozilla.org/show_bug.cgi?id=818340  patch matches how Safari has worked for years, and does the following:

    Allows cookies from sites you have already visited.
    Blocks cookies from sites you have not visited yet.

The idea is that if you have not visited a site (including the one to which you are navigating currently) and it wants to put a cookie on your computer, the site is likely not one you have heard of or have any relationship with. But this is only likely, not always true. Two problems arise:

False positives. For example, say you visit a site named foo.com, which embeds cookie-setting content from a site named foocdn.com. With the patch, Firefox sets cookies from foo.com because you visited it, yet blocks cookies from foocdn.com because you never visited foocdn.com directly, even though there is actually just one company behind both sites.

False negatives. Meanwhile, in the other direction, just because you visit a site once does not mean you are ok with it tracking you all over the Internet on unrelated sites, forever more. Suppose you click on an ad by accident, for example. Or a site you trust directly starts setting third-party cookies you do not want.

Our challenge is to find a way to address these sorts of cases. We are looking for more granularity than deciding automatically and exclusively based upon whether you visit a site or not, although that is often a good place to start the decision process.

We plan to ship an evolution of the patch “on” by default, but we want to make refinements first. To make sure we get this right we need more data. Our next engineering task is to add privacy-preserving code to measure how the patch affects real websites. We will also ask some of our Aurora and Beta users to opt-in to a study with deeper data collection.

There are many conflicting claims about how this patch will affect the Internet. Why debate in theory what we can measure in practice? We are going to find out more and adjust course as needed. This is the essence of the release test cycle.

On Tuesday we did two things:

    The patch has progressed to the Beta release channel for Firefox 22, but it is not “on” by default there. This allows more people to test the patch via Firefox’s “preferences” (AKA “options”) user interface, and avoids an abrupt change for site owners while we work on handling the hard cases.

    The patch remains in the Aurora channel for Firefox, where it is “on” by default. This gives the patch better ongoing test coverage and facilitates A/B testing.


We have heard important feedback from concerned site owners. We are always committed to user privacy, and remain committed to shipping a version of the patch that is “on” by default. We are mindful that this is an important change; we always knew it would take a little longer than most patches as we put it through its paces.

For those who read this as Mozilla softening our stance on protecting privacy and putting users first, in a word: no. False positives break sites that users intentionally visit. (Fortunately, we haven’t seen too many such problems, but greater testing scale is needed.) False negatives enable tracking where it is not wanted. The patch as-is needs more work.

We look forward to continued dialog with colleagues, contributors, fans, and detractors. We will update all of you within six weeks so you can understand our thinking and how we will proceed. Comments welcome.

---------------

P.S. Cookies (name history) were originally intended to be ephemeral (Windows 3.1 had so little usable memory with its 64K memory segments that Netscape’s founders had no choice). At first, they held only session state that could be recovered from the server by logging in again.

(Remind me to tell the story some day of Montulli’s aborted “twinkies” idea from the Netscape 2 era. UPDATE: Lou has published a new blog post   about cookies.)

How far we have come in the amazing, living system that is the Web! No one planned for what actually happened, but with more work on the cookie policy in Firefox and (I hope) other browsers, I believe that we can evolve to a better space.

https://brendaneich.com/2013/05/c-is-for-cookie/
« Last Edit: May 20, 2013, 08:07:01 AM by menotu »
PCLinuxOS 32bit KDE 4.10.1; kernel-3.4.11-pclos1.bfs & 64bit 3.2.18bfs; NVidia GeForce 8400GS 1GB 310.19 driver

Sony Vaio SVE1513A4ESI Laptop, Intel Core i5, 2.6GHz, 6GB RAM, 750GB, 15.6" Intel HD Graphics 4000