Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebKit Tracking Prevention Policy

webkit.org

Post reply on HN
Print view View original

161–170 of 254 posts

Re: WebKit Tracking Prevention Policy

#161

Post by om2 »

geofft wrote: post #50
eridius wrote: post #24

Earlier quoted context omitted.

I'm not sure what you mean by this; WebKit Tracking Prevention doesn't break third-party login. Third-party login works by handing a token back to the first party, who then stores it directly and validates it on the backend. After the initial login with the third party, the third party isn't involved anywhere that the browser can see. And the initial login happens in a browser window that's navigated directly to the…

TBH a browser prevents Medium from showing a Google iframe in the top-right corner with "Hi geofft, I know your name is geofft, please click the login button geofft," that would be delightful....

If you logged into Medium with that account, then Medium would know, and could tell the I frame. But if you didn’t, then the iframe shouldn’t know your user ID unless you click and allow access, at least in Safari.

Re: WebKit Tracking Prevention Policy

#162

Post by p4bl0 »

po wrote: post #148

A first party is a website that a user is intentionally and knowingly visiting, as displayed by the URL field of the browser, and the set of resources on the web operated by the same organization. In practice, we consider resources to belong to the same party if they are part of the same registrable domain: a public suffix plus one additional label. Example: site.example, www.site.example, and s.u.b.site.example are…

I think that's a problem for companies that owns multiple domains and want to track users between those. Browsers shouldn't have to help with that, but rather implement the most simple and efficient way of protecting their users, as long as it doesn't make the users' life more complicated. That's what should matter: users, not companies.

Re: WebKit Tracking Prevention Policy

#163

Post by p4bl0 »

Related to the way they classify between first party and third party (based on domain names, with its subdomain being the same party), the Public Suffix list [1] is a resource of great value. It allows to know when subdomains actually refers to different parties (e.g., xxx.github.io is neither the same party as yyy.github.io nor as github.io).

[1] https://publicsuffix.org/

Re: WebKit Tracking Prevention Policy

#164

Post by makomk »

briandear wrote: post #104
rale00 wrote: post #64

Earlier quoted context omitted.

> Didn't people make money off internet advertising before the modern surveillance-marketing complex? What happened to it? Non-contextual advertising still exists, but it's perceived as less effective, so there's a lot less money in it. I don't know if that perception is correct, but I do remember back when a common complaint from people was that the ads they saw weren't relevant to them. It's also not just targeted…

> No one wants to spend money showing ads to bots Bots can watch TV, somehow TV ads work. Newspapers have audited circulation, it wouldn’t be that hard to have a website visit audit company to verify “circulation.”

Auditing of TV and newspaper ads is done largely on the receiving side, not the sending side - companies monitor what's actually shown in the stations broadcast and papers sent to real people, they pay people to install monitoring devices to see what they watch, and they contact people to find out what they're reading. The internet equivalent isn't really possible on iOS without doing some kind of Facebook-esque end-run around Apple's walled garden and paying people to install non-Apple-approved monitoring apps - and even that would probably only work for really massive, broad advertising campaigns.

Re: WebKit Tracking Prevention Policy

#165

Post by quotemstr »

p4bl0 wrote: post #163

Related to the way they classify between first party and third party (based on domain names, with its subdomain being the same party), the Public Suffix list [1] is a resource of great value. It allows to know when subdomains actually refers to different parties (e.g., xxx.github.io is neither the same party as yyy.github.io nor as github.io). [1] https://publicsuffix.org/

The public suffix list is a gross hack. The public-ness of a particular domain level ought to be returned as part of the DNS response instead of being looked up out-of-band.

Re: WebKit Tracking Prevention Policy

#166

Post by p4bl0 »

quotemstr wrote: post #165
p4bl0 wrote: post #163

Related to the way they classify between first party and third party (based on domain names, with its subdomain being the same party), the Public Suffix list [1] is a resource of great value. It allows to know when subdomains actually refers to different parties (e.g., xxx.github.io is neither the same party as yyy.github.io nor as github.io). [1] https://publicsuffix.org/

The public suffix list is a gross hack. The public-ness of a particular domain level ought to be returned as part of the DNS response instead of being looked up out-of-band.

I understand your point, but the problem is that anybody can make their DNS response say whatever they want. And you can't even rely on crypto signatures (e.g. DNSSEC), as the people controlling some DNS records are not necessarily the same as their users.

For example, GitHub controls DNS for *.github.io so if they wanted to track people across all GitHub Pages, they could.

Also, the Public Suffix list isn't something that needs to be polled every time. It is reasonable for browsers to cache it for several days even.

Re: WebKit Tracking Prevention Policy

#167

Post by makomk »

wbl wrote: post #114
flyinglizard wrote: post #83

Earlier quoted context omitted.

The problem is that by doing that, you’re skimming the top percentile of your user base with the most purchasing power. You’re much less attractive to advertisers then.

Notice how the NY Times has subscriptions.

Which makes the New York Times very attractive to advertisers since they show adverts to their subscribers, meaning that they offer a pre-selected audience of people with higher purchasing power.

Re: WebKit Tracking Prevention Policy

#168

Post by babuskov »

redwall_hp wrote: post #124
jazzyjackson wrote: post #76

Earlier quoted context omitted.

From what I can tell, the pre-surveilence norm was businesses having to find a website with an audience they wanted to advertise to, or a website finding a business that might want to market to their users, and then every website having to negotiate contracts with every business that wanted to set up ads. Basically the print magazine model. But as businesses wanted to advertise to larger populations (we want to do a…

It was more profitable, especially for small sites. I used to cold email businesses and ask them if they wanted to buy a static banner on my blog, back in the 2000s. I made a few hundred a month on a site that had 30k views per month. You're lucky to get a fraction of that now. Advertisers get a much lower cost through AdSense and a ton of metrics.

I was in similar boat as you, but I think we look at the past with rose-tinted glasses.

You forget to factor in the time you spent to build the e-mail list, write a nice e-mail and send it, and repeat that every once in a while when people cancel. And you have to track payments, see if someone's credit cards runs out so they fail to renew the subscription, etc.

And let's not forget the fact that there was almost no competition - for businesses who didn't want to spend the time to research the Internet, the decision was most likely between advertising on your website or not advertising online at all.

BTW, you can still do that. I still go out, research and get people to advertise directly. I split the ad space on my website into premium and "regular" sections depending on page traffic and actual place on the page (header, footer, etc.). Premium has banners manually checked and contracted, hosted on the same domain as the rest of website's content, so no ad blocking and content very relevant to the website. The rest of space is filled with Google Ads. Premium banners earn about 5x more than Google Ads, but require that I maintain it. Google Ads just run without me having to do anything.

Re: WebKit Tracking Prevention Policy

#169

Post by feanaro »

qroshan wrote: post #94
rale00 wrote: post #40

So what is going to happen when Apple succeeds in making it impossible to make any money off advertisements shown to iOS users on the web? I'm currently imagining a future where publishers start to just redirect iOS traffic to install their app, where they can actually make money. Good news for the walled garden, I guess?

Most of HN don't understand that the Advertising ecosystem is what is feeding the tech boom and their livelihood. Just like housing it is an entire ecosystem now with many people's jobs and livelihood is based on. Hit that ecosystem and you get a recession. However it doesn't stop at the recession. Most VCs are funding hundreds and thousands of startups with the hope that one of them is going to get sold to Google or…

The sooner the ad nonsense stops, the sooner we can turn to finding profit in something more useful to humanity.

Re: WebKit Tracking Prevention Policy

#170

Post by hesarenu »

scarface74 wrote: post #28
elgenie wrote: post #27

Earlier quoted context omitted.

Well, how does a competitor make money on iOS without giving Apple a 30% cut of app installs and in-app purchases and/or using their ad network?

Simple, the same way that Spotify, Netflix, Amazon (Kindle), DirecTVNow, Sling, and a bunch of other companies do - force people to pay on their own websites to use the app.... Apple doesn’t have an “ad network”.

why can't they do it on their app?
Post reply on HN