AdIntuition Extension Highlights YouTube Videos Containing Affiliate Marketing–Google Removes It A Few Days Later

Researchers at Princeton’s Human-Computer Interaction Lab recently released a browser extension for Google Chrome and Firefox that highlights when a YouTube video includes sponsored content.

AdIntuition is a browser extension that alerts YouTube users when they watch a video containing a sponsorship. An influencer may endorse a product on social media, but it can be unclear if they were paid to endorse the product or if they genuinely endorse it without any incentive. The purpose of this research project was to automatically detect and disclose sponsored content to relieve users of the uncertainty about endorsements.

With the help of automatic disclosure software, content creators can no longer be deceptive about endorsements and viewers would be informed about any relationship between a social media influencer and a brand. AdIntuition is an automatic affiliate marketing disclosure tool that allows users to form an opinion about the content of a post with full information about sponsorships.

. . .

AdIntuition flags affiliate marketing, one type of social media marketing. In this type of marketing, a social media influencer provides a special link or coupon code, in addition to their endorsement of a product, in order to drive users to buy the product. Often a deal or promotion is given to users in the marketing campaign. The social media influencer is given a commission based off of the sales that they generate. Anyone can join an affiliate program.

Of course, Google almost immediately took down the Chrome extension, likely because the extensions does collect some information about the prevalance of affiliate marketing on YouTube for research purposes,

We will not share the data with anyone beyond our team. Our team is strictly interested in the research opportunities that the data will provide. We will not share your data for commercial purposes.

Silly researchers. Nobody shares information about Google users other than Google, and it better damn well be for commercial purposes.

Google Adding Some TLDs to Browser HSTS List Automatically

Apparently, Google is automatically adding some of its TLDs to browser HSTS lists–i.e., it is impossible to access any registered domains on those TLDs without using SSL on modern browsers.

As someone who likes to see as much Internet traffic encrypted by default, I think that’s kind of cool. As someone who owns quite a few domains on those TLDs, it is annoying that this was never disclosed when I purchased those domains.

Yes, HSTS is very good, but this can create some unexpected problems. There are occasionally situations where you may need to do an http call in the process of configuring or testing a site, and registrars need to be more upfront that this is not going to be possible with these Google-administered TLDs.

So Google has built HTTPS protection directly into a handful of top-level domains—the suffixes at the end of a URL like “.com.” Google added its internal .google top-level domain to the preload list in 2015 as a sort of pilot, and in 2017 the company started using the idea more extensively with its privately run suffixes “.foo” and “.dev.” But in May 2018, Google launched public registrations of “.app,” opening up automatic, preloaded encryption to anyone that wanted it. In February of this year, it opened up .dev to the public as well.

Which means that today, when you register a site through Google that uses “.app,” “.dev,” or “.page,” that page and any others you build off it are automatically added to a list that all mainstream browsers, including Chrome, Safari, Edge, Firefox, and Opera, check when they’re setting up encrypted web connections. It’s called the HTTPS Strict Transport Security preload list, or HSTS, and browsers use it to know which sites should only load as encrypted HTTPS automatically, rather than falling back to unencrypted HTTP in some circumstances. In short, it fully automates what can otherwise be a tricky scheme to set up.

“Web security stuff is complicated, and not every end user or even every site creator understands all of the complexities,” says Ben Fried, Google’s chief information officer. “The thing that I like about using these new top-level domains in this way is it dramatically decreases the burden on each site creator to get to the best practices. Nothing has to be done, because every subdomain in that top-level domain is HTTPS only and the browser won’t even try to access it any other way.”

The breakthrough moment came from engineer Ben McIlwain’s realization that an entire top-level domain could go on the preload list. “Internally it took off from there,” Fried says. “We realized these are two things that had developed independently that all of a sudden were way more powerful when combined.”

That Time Google Disabled My Account

Back in June 2017, I went to log in to my Gmail account when I received a message telling me that my account had been disabled:

Your Google Account is Temporarily Disabled

This was extremely concerning. I use Google services for a wide variety of services. While I regularly back up all my content from Google, if the company ever shut off my account it would cause a serious disruption in my life for a few weeks.

I followed the instructions and was able to access my account after logging in via the web using my two-factor authentication.

The strange thing, however, was that I had no idea what Google was referring to when they said my account had been disabled “because of a violation of our Terms of Service.”

I checked to make sure no one but myself had logged into my account, and there was no record of any access other than IP addresses that I use. As far as I know, none of the content I was storing on Google Drive or YouTube was in violation of any of Google’s TOSes.

I sent several emails to Google support and online trying to get an answer to what specifically  had trigger this action, but of course I never received any response. I assume that this was triggered by some sort of algorithm, and a couple of Google (!) searches shows that I’m hardly the first person to be hit with this sort of enigmatic warning and account disabling.

Google needs to be much more transparent about why it flags or disables accounts like this. Once I recovered my account, it should have given me a summary of exactly what triggered its algorithm.

As it is, in the months since then, I have curtailed some of my uses of Google products. Even though none of the contents on it were in violation of the TOS as far as I can tell, I removed almost all of the files I was syncing in Drive and switched over to Dropbox for file syncing.

If you’re a celebrity or academic, you can probably garner enough publicity to get your account restored if Google removes it. But it is disturbing that Google would simply disable an account that I use to organize my life and job and then refuse to respond or explain its actions. Someday you could wake up and find that Google has simply deleted your account with absolutely zero recourse available.

Google’s Rank Hypocrisy on Security Patches

Mateusz Jerczyk of Google Project Zero calls out Microsoft for implementing some security patches in Windows 10, but not Windows 7 and 8.1.

The aim of this blog post was to illustrate that security-relevant differences in concurrently supported branches of a single product may be used by malicious actors to pinpoint significant weaknesses or just regular bugs in the more dated versions of said software. Not only does it leave some customers exposed to attacks, but it also visibly reveals what the attack vectors are, which works directly against user security. This is especially true for bug classes with obvious fixes, such as kernel memory disclosure and the added memset calls. The “binary diffing” process discussed in this post was in fact pseudocode-level diffing that didn’t require much low-level expertise or knowledge of the operating system internals. It could have been easily used by non-advanced attackers to identify the three mentioned vulnerabilities (CVE-2017-8680, CVE-2017-8684, CVE-2017-8685) with very little effort. We hope that these were some of the very few instances of such “low hanging fruit” being accessible to researchers through diffing, and we encourage software vendors to make sure of it by applying security improvements consistently across all supported versions of their software.

On the one hand, he’s correct. Microsoft is leaving users of Windows 7/8.1 exposed to potential security risks by not patching those OSes, and they should be “encourage[d] . . .to make sure of it by applying security improvements across all supported versions of their software.”

On the other hand, it’s a bit rich of Google to be lecturing Microsoft for not patching older OSes. Take Windows 7. That OS was released on July 22, 2009 and mainstream support for it ended on January 13, 2015. Microsoft is committed to providing extended support, however, through January 14, 2020.

So Google is unhappy that 8 years after releasing Windows 7 that Microsoft failed to implement a security patch for a known vulnerability. Fair enough.

On July 9, 2012, Google released Android 4.1 Jelly Bean. A major vulnerability in Android 4.1 was discovered in early 2015. In January 2015, Google publicly announced that it would not develop a security patch for this bug for Android 4.1. It did graciously allow that if someone else wanted to develop a security patch for the 2-and-a-half year old OS that it might be willing to incorporate those into Android 4.1.

Unlike Microsoft, Google can’t even be bothered to publish formal end-of-life dates for its software. The only policy it has in place is related to its own Nexus and Pixel devices, and states that such devices will receive “security patches for at least 3 years from when the device first became available on the Google Store, or at least 18 months from when the Google Store last sold the device.”

Compared to Google, Microsoft is a paragon of virtue when it comes to supporting its customers on aging OSes.