Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

1/28/2013
02:42 PM
Connect Directly
LinkedIn
Twitter
RSS
E-Mail
50%
50%

Google Faces Safari Privacy Claim In U.K.

Google is attempting to have similar claims dismissed in the U.S. for lack of harm.

10 Best Business Tools In Google+
10 Best Business Tools In Google+
(click image for larger view and for slideshow)
Overlooking the irony of fighting for privacy on a social network, a few users of Apple's Safari browser in the United Kingdom have marked Data Privacy Day by launching a Facebook page to coordinate possible legal claims against Google. The group seeks to punish Google for bypassing privacy controls in Apple's Safari browser on desktop and mobile devices as a means to present personalized content.

The law firm Olswang has been retained to coordinate any claims. The first claimant, Judith Vidal-Hall, said in a statement, "Google claims it does not collect personal data but doesn't say who decides what information is 'personal.' Whether something is private or not should be up to the Internet surfer, not Google. We are best placed to decide, not them."

Google's circumvention of privacy controls in Safari was revealed in February 2012 by Stanford graduate student Jonathan Mayer. Rachel Whetstone, Google's SVP of communications and public policy, explained at the time that the company bypassed Safari's controls "to enable features for signed-in Google users on Safari who had opted to see personalized ads and other content -- such as the ability to '+1' things that interest them."

[ Are you finding your access to some apps being restricted? Read Facebook Blocks Vine, Wonder Apps. ]

In November, Google agreed to pay $22.5 million to settle a Federal Trade Commission claim that it had violated a previous agreement with the agency by misrepresenting privacy assurances affecting users of Apple's Safari browser. It did so denying that it had violated its FTC consent decree.

Google declined to comment. But a week ago, the company asked for the dismissal of a similar case brought in the U.S. because its placement of cookies didn't really harm anyone.

In its filing, Google explains that what happened was an unforeseen consequence of developing a Google+ feature that allowed Google+ users to see personalized content. It did so by developing what it calls an Intermediary Cookie, to serve personalized content without breaching the anonymity that users are afforded on its ad network.

Apple's Safari browser defaults to blocking third-party cookies, which are used by ad networks. But it allows exceptions under certain circumstances. One exception is what's known as the "Safari One In, All In Rule," which allows all cookies from a given domain if one from that domain has already been stored in the user's browser. Another is the "Safari Form Submission Rule," which allows cookies from a third-party domain if the user submitted a form from that domain.

Google used the "Safari Form Submission Rule" to place its Intermediary Cookie and inadvertently opened Safari's doors to any cookie under the "Safari One In, All In Rule." As a consequence, Safari users began accepting cookies from Google's DoubleClick ad network despite representations to the contrary.

"To the extent that this unexpected outcome had any effect, it is only that a more tailored ad may have been displayed to the browser than otherwise would have been," Google said in its legal filing, noting that no specific harm had been documented as a result of its actions.

Dan Tench, a partner at Olswang, dismissed Google's explanation in an email. "We do not know what Google's response to our clients' complaints will be since we have received no reply to our letters," he said. "In any event, Google's explanation for its secret tracking would be no answer to our clients' complaints under U.K. law."

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
News
Former CISA Director Chris Krebs Discusses Risk Management & Threat Intel
Kelly Sheridan, Staff Editor, Dark Reading,  2/23/2021
Edge-DRsplash-10-edge-articles
Security + Fraud Protection: Your One-Two Punch Against Cyberattacks
Joshua Goldfarb, Director of Product Management at F5,  2/23/2021
News
Cybercrime Groups More Prolific, Focus on Healthcare in 2020
Robert Lemos, Contributing Writer,  2/22/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Building the SOC of the Future
Building the SOC of the Future
Digital transformation, cloud-focused attacks, and a worldwide pandemic. The past year has changed the way business works and the way security teams operate. There is no going back.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-27132
PUBLISHED: 2021-02-27
SerComm AG Combo VD625 AGSOT_2.1.0 devices allow CRLF injection (for HTTP header injection) in the download function via the Content-Disposition header.
CVE-2021-25284
PUBLISHED: 2021-02-27
An issue was discovered in through SaltStack Salt before 3002.5. salt.modules.cmdmod can log credentials to the info or error log level.
CVE-2021-3144
PUBLISHED: 2021-02-27
In SaltStack Salt before 3002.5, eauth tokens can be used once after expiration. (They might be used to run command against the salt master or minions.)
CVE-2021-3148
PUBLISHED: 2021-02-27
An issue was discovered in SaltStack Salt before 3002.5. Sending crafted web requests to the Salt API can result in salt.utils.thin.gen_thin() command injection because of different handling of single versus double quotes. This is related to salt/utils/thin.py.
CVE-2021-3151
PUBLISHED: 2021-02-27
i-doit before 1.16.0 is affected by Stored Cross-Site Scripting (XSS) issues that could allow remote authenticated attackers to inject arbitrary web script or HTML via C__MONITORING__CONFIG__TITLE, SM2__C__MONITORING__CONFIG__TITLE, C__MONITORING__CONFIG__PATH, SM2__C__MONITORING__CONFIG__PATH, C__M...