Third-party cookies have been the lynchpin of online advertising for many years. Plans to phase cookies out forever continue to run at a steady pace, with Google in the driving seat. In 2019, it announced its vision for a “Privacy Sandbox”. The building blocks for this were essentially:
- Most aspects of the web need money to survive, and advertising that relies on cookies is the dominant revenue stream.
- Blocking ads or cookies can prevent advertisers from generating revenue, threatening #1.
- If you block easily controllable methods like cookies, advertisers may turn to other techniques, like fingerprinting, that are harder for users to control.
The Privacy Sandbox mission is to “Create a thriving web ecosystem that is respectful of users and private by default”. The intention is to create a set of rules that will work well for everybody. No third-party cookies, no incredibly specific individual marketing profiles, and data is kept on your device as much as possible. User data is anonymised and grouped into “cohorts”, and those cohorts with similar interests will then see targeted ads. In this way, users aren’t compromising privacy and advertisers can still deliver targeted ads, but will struggle to map out individual identities.
Broadening the scope of user privacy
This all sounds reasonable enough. A push for standards where user data sharing is greatly reduced, but ads can still function as intended is likely much better than what we have now. The wheels often come off on long-term plans like this, so it is to their credit it’s still very much happening.
You can see some aspects of web control already offered by Google in this blog from 2019:
- My Activity: Look at searches, websites visited, videos watched. It’s sort of like your browser history, but on a grand Google scale, with options to disable aspects of search or location.
- Ad Settings: Possibly the most relevant to this subject, as it shows how your ads are personalised. This is done via data you’ve added, Google’s best guesses, and data from advertisers partnered with Google. My standout highlight was the assumption I’m into extreme sports, flower arranging, and country music. I guess I’m obscuring my actual interests in a very privacy conscious fashion.
They also explain at length why you see specific ads, and also how to opt out.
Slow and steady wins the race?
Tackling third-party cookies isn’t a particularly new idea, and both Safari and Firefox have been bringing the hammer down, to various degrees of severity. But the companies behind those browsers don’t depend on ad revenue in the way that Google does. Which is why what Google is attempting is not a straightforward ban; it’s trying to find ways to replace the old system entirely. There are many, many arguments about this subject. Some advertisers claim organisations are doing this to keep users behind their own walled garden of advertising and tracking. Others say whatever you replace the old system with, will either be ignored or worked around.
This last point has some validity to it. While the major advertising players will probably work with the new methods, this leaves a gap in the market for shenanigans. Not everybody will play nice. Many smaller networks are entirely reliant on individual tracking. In some cases, they may not be able to adapt—or might not want to.
Tearing up the rulebook
CNAME cloaking, where analytics firms make third-party cookies look like first-party cookies to get around ad-blocking, has been in the news recently. We can expect a lot more of these tactics as the inevitable demise of third-party cookies draws closer.
Much is still unknown about the proposed replacements too. We don’t know exactly how people might extract themselves from specific cohorts should they feel the need to, for example. Or even if it will be possible. If I see targeted, extreme-sport-flower-arranging ads all over the place, what options are available to “fix” it?
These are good questions to ponder while Privacy Sandbox continues its 2 year plan to bring the curtain down on the ubiquitous third-party cookie. We look forward to seeing what comes next, and cast a cautious eye in the direction of ad networks everywhere.
The post Will Google’s Privacy Sandbox take the bite out of tracking cookies? appeared first on Malwarebytes Labs.
Google’s bug bounty has been expanded to not only covers the firm’s own products, but additionally all apps in the official Google Play store which have had 100 million or more installs.
Read more in my article on the Hot for Security blog.
Bug hunter Thomas Orlita discovered an XSS vulnerability in Google’s Invoice Submission Portal that would have allowed attackers access to Google’s internal network
The Czech researcher Thomas Orlita discovered an XSS vulnerability in Google’s Invoice Submission Portal that would have allowed attackers access to part of Google’s internal network.
The Google Invoice Submission Portal is a public portal used by Google’s business partners to submit invoices.
An attacker could also exploit the flaw to steal Google employee cookies for internal apps and hijack accounts or send spear-phishing messages.
The attack was devised by the expert in February, and Google addressed the issue in mid-April after the researcher reported it to the tech giant.
Orlita explained that an attacker could have uploaded malformed files in the Google Invoice Submission Portal, via the Upload Invoice field.
The expert noticed that the ‘upload’ feature for actual invoice in PDF format could be abused to upload HTML files. The attacker had to intercept a request and change the uploaded file’s filename and Content-Type properties to HTML.
Using this trick it was possible to store malicious files in Google’s invoicing system and would have executed automatically when an employee tried to access it.
“Since this is just a front-end validation, it doesn’t stop us from changing the file type when sending the upload POST request. Once we select any PDF file, an upload request is fired. We can intercept the request using a web proxy debugger and change the filename and the contents from .pdf to .html.” reads the analysis published by the expert.
Orlita uploaded an HTML file including an XSS payload that, when triggered, would send him an email every time it was loaded.
A few days later, the expert received an email message showing that the JavaScript code in the XSS payload had been executed on the googleplex.com domain.
This domain is used by Google for hosting internal websites and apps. If you attempt to access the domain you will be redirected to a Google Corp login page for Google employees that requires the authentication.
“The DOM of the page matches the XSS payload that was put instead of the PDF file. We can see that this URL is used for displaying a PDF file. But since the Content-Type of the uploaded file was changed from application/pdf to text/html, it displayed and rendered the XSS payload instead of the PDF.” continues the expert.
According to the researcher, it was possible to exploit the flaw to execute arbitrary code on behalf of Google employees and gain access to sensitive information.
The expert pointed out that many Google internal apps are hosted on the googleplex.com domain, making this issue a gift for the attackers,
Below the timeline for the flaw:
21.02.2019: Vulnerability reported
22.02.2019: Priority changed to P2
22.02.2019: Added more information
25.02.2019: Accepted and priority changed to P1
06.03.2019: Reward issued
26.03.2019: A fix has been implemented
11.04.2019: Issue marked as fixed
|
|
Pierluigi Paganini
(
The post XSS flaw would have allowed hackers access to Google’s network and impersonate its employees appeared first on Security Affairs.
In October of 2018 my site was hit by a meteor called Google.
My traffic dropped by over 60% in just a couple of weeks—going from around 10,000 pageviews a day, to around 4,000.
Read about the March 2018 Update
After some research and help from Thomas Zickell, I knew that this was a Google algorithm update, but I still decided to tend to my SEO garden to see if I could help the situation.
Here are some of the things I did:
I’ve been blogging since 1999, so I have thousands of posts.
- Removed hundreds of old, personally-relevant (but not publicly useful) posts
- Removed lots of thin content
- Updated some of the metadata for the site
- Refreshed a few of my key pages
- Changed my top-level nav
- Added sub-menus to my top-level nav
- Added anchor pages for Information Security and Cybersecurity
- Other minor tweaks
I also had a recent article go viral due to some famous associates sharing it on Twitter, so that probably had an impact as well.
As is usually the case, you never know what exactly is working, or if Google is changing things on their side. But to me the graph matches the March Update pretty clearly.
I am sure there were many factors, but it seems clear that the March Core Update was a major one.
Many people are saying that this update reversed a lot of damage done to some sites in 2018, and I think that’s definitely true for me.
I was really worried that I was being punished because I talk about so many different topics on my site, and that I’d never make it back. But I noticed something while my traffic was low that gave me hope: many of the pages that ranked higher than me were really, really bad.
That told me that this wasn’t a policy change, but rather experimentation with something that would likely be fixed in the future for the benefit of users.
And that seems to be exactly what happened. I’m now up over 25,000 spots on Alexa, to sub-100K again.
Anyway, I hope this helps someone who might be going through something similar.
—
Become a direct supporter of my content for less than a latte a month ($ 50/year) and get the Unsupervised Learning podcast and newsletter every week instead of just twice a month, plus access to the member portal that includes all member content.