Live data from Hacker News

WebKit Tracking Prevention Policy

webkit.org

131–140 of 254 posts

Re: WebKit Tracking Prevention Policy

#131
post #50
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....

You can achieve that with firefox containers or - if you want a bigger hammer - first-party isolation.

Re: WebKit Tracking Prevention Policy

#132
post #89

Earlier quoted context omitted.

Luckily for this discussion, the word 'monopoly' has an accepted definition, which is: > The exclusive possession or control of the supply of or trade in a commodity or service Since Apple has, at most, below 50% market share in developed countries (and a much lower market share in developing countries), they do not possess a monopoly on the smartphone market.

By your given definition, Google isn't a monopoly either as there are clear alternatives to them in every sector that they are in.

Although the definition the other user posted was too strong, it was mitigated by the observation that Apple is barely 50%.

If we compare Google's marketshare in end user email, video hosting and search, we can see Google is a lot stronger in many markets, than apple is in their best market.

(I wish I could use an iPhone, but having to use Mac OS for development is a real turn off, considering how sucky Mac OS, in my view, has ever been.)

Re: WebKit Tracking Prevention Policy

#133
post #117

I expect that tracking will just move to being proxied server side. It will be more annoying for the people setting it up but services will spring up to help. Little will change in the advertising and tracking space.

It's actually pretty hard to do this. You still need some way to consistently identify the same user across different sites. Stateful tracking, fingerprinting, and link decoration are the only ways we know of to do this and we have our sights set on all of them.

Isn’t link decoration an intractable problem? Ban query params and people switch to matrix params. Ban that and they subtly include it in the seo friendly text, band that and…

It just seems somewhat wrong that a browser with a huge market share doesn’t use any standards / rfc process and invents new ways of blocking tracking / breaking agreed upon specifications from release to release in isolation.

Re: WebKit Tracking Prevention Policy

#135
post #93

Earlier quoted context omitted.

> Basically the print magazine model. And also TV, as it is still today. Oh, and every other form of advertising basically. If advertising without invading user privacy is so bad (as the perpetrators are rationalizing it), how come all other forms of advertising are still a billion (trillion?) dollar business worldwide? Just makes one wonder.

Broadcast TV, not Internet TV. It’s valid for broadcast antenna and cable TV, because those can’t be tracked, but it’s not valid for smart TVs, smart cable boxes, or almost all Internet TV sources — as those are all generally subject to the same level of invasive tracking using the account credentials.

You're right of course. I was indeed talking only about the old-school TV.

Re: WebKit Tracking Prevention Policy

#136
post #134
post #113

It is worth reminding that Google Chrome and Chromium no longer use WebKit but Blink. https://www.chromium.org/blink

Wow, thanks. Somehow I missed that. Things move so fast.

Google forked WebKit (itself a fork of KDE Konqueror's KHTML). Blink is from 2013. [1]

I wonder how source incompatible these are? Is it difficult to backport? Because KHTML was LGPL the source must remain available. Or is it just that these are API incompatible?

https://en.m.wikipedia.org/wiki/Blink_(browser_engine)

Re: WebKit Tracking Prevention Policy

#137

Earlier quoted context omitted.

There is also the ongoing escalation between adverrtisers and fraud. Creating an incentive to collect ever more data to detect ever more sophisticated forms of fraud.

How is fraud handled for TV advertising? Or print? This isn’t some weird new problem. The truth is that ad-tech wants to track you to make your profile more valuable, however, a less valuable user doesn’t mean advertising doesn’t work, it just means the bottom-feeding middlemen get a less profound payday. Why not just flip the model from eyeballs and clicks to actual ad effectiveness? Newspaper car ads have this down…

if you are a publisher and have actual content humans care about, ditch the ad networks and start selling your pixels directly to relevant advertisers.

Good luck with direct ad sales, unless you are a large company with a large ad sales team and correspondingly large budget.

Re: WebKit Tracking Prevention Policy

#138

Earlier quoted context omitted.

Yes. The walled garden of AAPL. Spend money in an app, Apple gets a cut. As it is, Google and Facebook get the revenue instead.

As an end user I’d rather have it be this way though. At least under this model I can download apps and vote with my wallet.

And if every website becomes an app because that's the only way to make money, the distributed, decentralize web dies in favor of one giant app store.

Is that what you want? Most of human culture behind app based paywalls? No more archive.org content to preserve. Micropayments everywhere?

Can you imagine the cognitive burden of continuously, always, purchasing stuff? Of the effect on the have-nots for whom deciding to pay money for commodity content vs immediate needs is a much more important decision?

Re: WebKit Tracking Prevention Policy

#139

Earlier quoted context omitted.

Google makes $21 on average per US user per month [1], almost all of which comes from advertising. Would you pay $21/mo for your Google services? [1] https://mondaynote.com/the-arpus-of-the-big-four-dwarf-every...

I’ve bought zero products via google ads, except the case when I search for a company name and their official homepage is the top sponsored result. Which is insane. And yet, my eyeballs looking at text with less text than a tweet is worth 21 USD. It feels like Google disrupted, but it’s far away from being optimal for companies.

$21 per user per month, on average, doesn’t imply $21 on you, every single month.

Other users react differently to that advertiser and/or you may click once every few years to bring in $1,000 advertising revenue for them on a very high-margin item.

Re: WebKit Tracking Prevention Policy

#140

Earlier quoted context omitted.

Google makes $21 on average per US user per month [1], almost all of which comes from advertising. Would you pay $21/mo for your Google services? [1] https://mondaynote.com/the-arpus-of-the-big-four-dwarf-every...

I’ve bought zero products via google ads, except the case when I search for a company name and their official homepage is the top sponsored result. Which is insane. And yet, my eyeballs looking at text with less text than a tweet is worth 21 USD. It feels like Google disrupted, but it’s far away from being optimal for companies.

Just because you've not bought something by clicking on an ad doesn't mean that the advertising has changed your purchasing habits.

...unless you are magically immune from advertising?

Post reply on HN