Third party cookies must be removed
w3ctag.github.io
w3ctag.github.io
Section 2: Third party cookies have gotten bad. Ok.
Section 3: There are legitimate use cases that third party cookies currently cover. Also ok. Then they throw in, "Be aware that a set of new technologies which carry minimal risk individually, could be used in combination for tracking or profiling of web users." Yes? Huge scope increase in the document though and all of a sudden we're now talking about tons of tracking technologies in aggregate? The authors move on without further comment.
Section 4: I think the first half is essentially saying that new technology coming online in the web platform will make the third party cookie problem worse, so we should fix it soon. OK, I'm with back with you. Then the document suddenly pivots to proposing general standards for web privacy again, saying that the burden of proof is on the people originating the proposal to, before concluding by saying (apparently without irony?) that justifying the removal of third-party cookies' impact on business is outside of the scope of the document.
I'm missing a ton of cultural context here about how W3C works, so I'm guessing this probably amounts to rough notes that somebody intends to clean up later that I'm being overly critical of, and they didn't expect it to get any traction on hacker news.
(I did not say it is a realistic goal for a theoretical comitee)
No. It's sabotage.
i don't understand how everyone ignores that w3c is mostly staffed by companies in adtech.
their goal is to keep adtech viable and profitable. Microsoft with ie, and then google with chrome, are just extra pushes to this end. but the main effort is w3c.
disclaimer: was one of the aforementioned grunts in a more naive life.
It's just that with the modern Web 7.0 (or whatever version we're on now), it's WHATWG that's most prominent since there's that one spec that defines 90% of what happens on the Web, it's called "The HTML standard" or some such. Then you have Google de-facto authoring specs., which may or may not find their way back into the HTML document, but even if they don't, they do make you feel like W3C is left behind.
Which is just going to be in additional to 3rd-party cookies. Google's own study concluded removing 3rd-party cookies loses revenue and "privacy-preserving" tracking increases revenue: https://support.google.com/admanager/answer/15189422 So they'll just do both: https://privacysandbox.com/news/privacy-sandbox-next-steps/
I’ve also been experimenting with Zen[1], which is Firefox based, recently and it seems quite promising in terms of a nicer default UI.
[0] I like Tab Stash, Vimium C, SponsorBlock, Decentraleyes, DeArrow, Archive Page, among others
#!/bin/sh
if [ -z $CHROME ]; then
test -e "$(which chromium)" && CHROME="chromium"
test -e "$(which google-chrome)" && CHROME="google-chrome"
test -e "$(which google-chrome-stable)" && CHROME="google-chrome-stable"
test -e "$(which google-chrome-dev)" && CHROME="google-chrome-dev"
fi
TMPDIR=$(mktemp -d /dev/shm/chrome-XXXXX)
$CHROME --user-data-dir=$TMPDIR --no-first-run --no-default-browser-check "$@"
rm -rf $TMPDIRnot privacy
https://blog.mozilla.org/en/mozilla/mozilla-anonym-raising-t...
Owned by Mozilla, ran by ex-Facebook employees. I'm sure it's entirely coincidentally this W3C draft was written by Mozilla and Facebook employees.
I feel like storing my "preferences" locally without letting me edit them as a stupid move.
Wow.
but if you cannot have a third party cookie, the remote site from the tracker cannot be sure that the script was actually downloaded, nor executed.
I could even see a data broker centralizing this and distributing tracking to all of their clients. The client would just need to communicate with the central broker, which is not hard at all.
BTW, I see this as a feature, not a bug. I'm glad it would be harder and more expensive to violate my privacy.
https://www.freepatentsonline.com/8990330.html
The next step will be to strict JS. Im for it.
That script would execute with the origin of the server. It's access to resources and /shared state/ would be hampered by this. So as a cross-site tracking strategy I don't think this works.
> I don't understand how this helps the web unless protections against tracking itself, not the methods used, are established.
Which is why I think state partitioning[0] and CHIPs[1] are good technologies. It allows previously existing standards, like cookies, to continue to exist and function mostly as expected, but provides the user a good amount of default security against cross site trackers and other malware.
[0]: https://developer.mozilla.org/en-US/docs/Web/Privacy/Guides/...
[1]: https://developer.mozilla.org/en-US/docs/Web/Privacy/Guides/...
The workaround is looking more and more like IP, fingerprinting, and AI. I’d argue this is worse than 3p cookies, which were at least dumb and easy to clear.
The only one I can think of is if there is a single logical site spread across multiple domains, and you want to be able to maintain a single session across both domains, but are not willing (for aesthetic reasons or technical reasons) to encode this information in the links while moving between domains.
Are there others?
As far as I'm concerned I don't even want first-party cookies to be available when accessed through a third-party context (i.e. if I have a cookie on a.com, and b.com fetches an image from a.com, I don't want that image request to send my a.com cookie).
My preference for this entire discussion is that we eliminate cookies entirely, but use self-signed client certificates very aggressively. When you navigate to a url the user agents sends a client certificate specific to that domain. Any subsidiary fetches use a (deterministic) scoped client certificate specific to the subsidiary domain. All other state tracking is required to be server-side and linked to the certificate. The user can instruct their user agent to reset any of these.
Embeds
1. As a user in BigCorp I want to embed this new AI reporting software into my larger internal portal for certain groups so they can try it out. The embedded software needs to know who the user is for authorization purposes. 2. As an end user of multiple appliance websites I would like to not have to enter my information multiple times into the support chat bot since all of these various companies are all part of the same overarching corporation and they already know my information. 3. As an end user of multiple blogs all using the same third-party commenting system I would like to already be logged in on foo.blog if I logged in earlier on bar.weblog.
These are all nice convenience features that builders and end users have gotten used to. They can all be achieved in other ways. The other ways are more painful to integrate and require a lot more work both on the part of the integrator and on the part of the end user (at least from a machine perspective - consider how much more work a pre-authenticated (no end-user-visible interstitial screens) OAUth flow is from the browser's perspective than a single request with an attached cookie).
Case 3 feels the most like a legitimate use case. Even with url parameters, there's no way for Disqus (or whatever) to know that a.com's user is the same person as b.com's user since those are independent entities. It is still solvable, but not in a zero-click way, by having a round-trip redirect (like an OAuth flow), to associate my user on the blog with my user on the commenting platform. But that does require that the blog track my session, which is not a requirement in the current world.
On the other hand, I'm not sure how much I like having #3 work in general -- that a blog commenting platform can implicitly know what blogs I'm visiting, and potentially even having a blog on which I have no account implicitly having access to my account on other blogs, feels a bit intrusive to me. I'd rather have that integration at the level of a browser extension that modifies user agent behavior rather than something that happens without my permission.
Any URL parameter that isn't signed is going to be modified (Look at me, I'm the CEO now). And if it is signed then it can be leaked (web app logs generally log query string parameters, if it's in a link that can be copy-pasted then it can be widely shared by accident, etc.)
> On the other hand, I'm not sure how much I like having #3 work in general
Yeah, that is another potential architecture for the web (kind of like Project Xanadu: https://en.wikipedia.org/wiki/Project_Xanadu). It isn't how the web is currently built, so the real question is "how much of the web should break?"
Is there really need for this? I get subdomains can help routing, but beyond that sites spreading over multiple domains are chaotic and phishing-prone. People get used to jump from foo.com to foo.net or scammyfoo.tk and enter their credentials if they look similar. I think that a big part of how password managers help is by keeping passwords from their users and not sharing them with any random domain that may read similar or misleading.
It's fine and all to assume that domain is identity, but that doesn't actually map too well to relatively complex organizational hierarchies.
Ex - Bank A and Bank B merge. There is going to be a period where they have to navigate that two domains represent a single organization. It's often a fairly high level of effort to move to a completely new domain, and it won't be done overnight.
Yes - eventually you want to be back on a single domain, and I think there is definitely a world where this leads to some very bad patterns (HR and healthcare are two examples - if you've ever seen a login need to bounce between like 5 different domains because they've refused to actually do the technical work to consolidate back on a single domain, and treat the domain as marketing).
But it's a really valid spot to end up in, and is the most common cause of having a single entity spread out over multiple domains in my experience.
Imagine an easy-to-use website builder for restaurants where each restaurant gets a memorable domain, and they let you order things online. It would be great for customers if they didn't have to enter their payment details and shipping address for each new restaurant they order from. Maybe they could even see opening hours and product availability for the closest restaurant to their address. There's no privacy risk here, as all these websites are actually on a single provider anyway. They're just multiple entries in some SQL database, each with a `domain` associated with them.
For a modern example, restaurants have online ordering systems. And a lot of them use the same service under the hood. (Eg toast.) If you want to use the same credit card you used somewhere else, you have to login on every single restaurant site using the SMS code. (Eg “link pay.”) Allowing 3rd party cookies would make that flow faster, since you could visit other restaurant’s domains while still being logged into the 3rd party payment domain. (And specifically, logged-in inside an iframe so the restaurant site can’t read your payment info.)
Take the web hosting example; naively if I visit any site hosted by that company, can they detect that I have an account and am logged in to my hosting account? That feels like a dangerous amount of leakage, and you're relying on the hosting website to make the correct restrictions rather than having it structurally embedded in the user agent.
The shared payment system feels even worse -- is it then possible for a random website to get a payment through this system, or extract information about my payment account?
None, looking at it from a web users' perspective
You can make up scenarios that require them, but these are artificial and contrived, and boil down to "I can extract more value"
When you are the one extracting value, and you are an articulate intelligent person, I expect you will have screeds and screeds of logical sounding reasons why third party cookies are good for me as a web user.
You would be wrong
I have been deleting them for years.
Nothing is private: https://nothingprivate.gkr.pw
More effort ought to be put into how to make web spec to NOT be able track user even if JS is turned on.
Browser vendor Brave, Firefox suppose to privacy browser are NOT doing anything about it.
At this point, do we need to using JS disabled browser to really get privacy on the web?
My thoughts are that we need a distinction between web pages (no JS) which are minimally interactive documents that are safe to view, and web apps (sites as they exist now) which require considerable trust to allow on your device. Of course, looking that the average person's installed app list indicates that we have a long way to go culturally with regards to establishing a good sense of digital hygiene, even for native software.
While I am all in favor of continuing the technical battle against tracking, it’s time to recognize that the war will only be won with legislation.
[1] https://addons.mozilla.org/en-US/firefox/addon/multi-account...
My gut says no, not possible.
Maybe we need a much lighter way to express logic for UI interactions. Declarative is nice, so maybe CSS grows?
But I don’t see how executing server-controlled JS could ever protect privacy.
you stand out when you obviously hide
It's why tor browser is set to a specific dimension (in terms of pixel size), have the same set of available fonts etc.
But if privacy is truly the desired goal, the regular browser ought to behave just like tor-browser.
You could make something similar where fingerprint worthy information cant be posted or used to build an url. For example, you read the screen size then add it to an array. The array is "poisoned" and cant be posted anymore. If you use the screen size for anything those things and everything affected may stay readable but are poisoned too. New fingerprinting methods can be added as they are found. Complex calculations and downloads might make time temporarily into a sensitive value too.
In those scenarios, tainted variables were ones which were read from untrusted sources, so could cause unexpected behaviour if made part of SQL strings, shell commands, or used to assemble html pages for users. Taint checking was a way of preventing potentially dangerous variables being sent to vulnerable places.
In your scenario, poisoned variables function similarly, but with "untrusted" and "vulnerable" being replaced with "secret" and "public" respectively. Variables read from privacy-compromising sources (e.g. screen size) become poisoned, and poisoned values can't be written to public locations like urls.
There's still some potential to leak information without using the poisoned variables directly, based on conditional behaviour - some variation on
if posioned_screenwidth < poisoned_screenheight then load(mobile_css) else load(desktop_css)
Like opening a window requires a click (in the chain of events), load() wouldn't work in a tainted conditional.
Just create _strict_ content security profile, which doesn't allow any external requests (fetch) and only allow load of resources (css, image, whatever) from predefined manifest.
App cannot exfiltrate any data in that case.
You may add permissions mechanisms of course (local disk, some cloud user controls, etc).
That's a big challenge in standards and not sure if anyone is working on such strongly restricted profile for web/js.
Yes, of course: restrict its network access. If JS can't phone home, it can't track you. This obviously lets you continue to write apps that play in a DOM sandbox (such as games) without network access.
You could also have an API whereby users can allow the JS application to connect to a server of the user's choosing. If that API works similarly to an open/save dialog (controlled entirely by the browser) then the app developer has no control over which servers the user connects to, thus cannot track the user unless they deliberately choose to connect to the developer's server.
This is of course how desktop apps worked back in the day. An FTP client couldn't track you. You could connect to whatever FTP server you wanted to. Only the server you chose to connect to has any ability to log your activity.
Don't want to be tracked. Don't go on the internet.
The comments on the story are completely unconvinced that anyone at Apple will ever be convicted. Any fines for the company are almost guaranteed to be a slap on the wrist since they stand to lose more money by complying with the law.
I think the same could be said about anti-cookie/anti-tracking legislation. This is an industry with trillions of dollars at stake. Who is going to levy the trillions of dollars in fines to rein it in? No one.
With a technological solution at least users stand a chance. A 3rd party browser like Ladybird could implement it. Or even a browser extension with the right APIs. Technology empowers users. Legislation is the tool of those already in power.
and how does one know their privacy has been invaded? How does the user know to enforce the DMCA law for privacy?
I think the solution has to be technological. Just like encryption, we need some sort of standard to ensure all browsers are identical and unidentifiable (unless the user _chooses_ to be identified - like logging in). Tor-browser is on the right track.
What am I supposed to witness?
I opened the website on non anonymous session safari: it asked my name. Then I opened another new non anonymous window on the same browser: it showed my name as expected. I then opened the same browser in incognito mode: it asked my name again. I then opened chrome (non anonymous) and again it asked my name.
Exactly what I expected to see; everything seems to be working as intended. Anonymization online seems to be working perfectly fine.
What we need to do is turn the hoarding of personal information into a literal crime. They should be scrambling to forget all about us the second our business with them is concluded, not compiling dossiers on us as though they were clandestine intelligence agencies.
They run arbritrary code from sketchy servers called "websites" on people's hardware with way too many privileges. While free and open source standalone web applications exist that only use minimal JS code to access the same web resources with a much better user experience. Without trackers, without ads and third parties.
I don’t mean to sound glib. But people derive a ton of utility from the web as it stands today. If they were asked if they supported the removal of web browsers they would absolutely say no. The privacy costs are worth the gains. If you want change you have to tackle that perception.
Not intending to sound snarky but do you just not use the web much? Or if you're adding allows all the time, what's the net gain?
I also set temporary permissions for any site I dont think I will be spending a lot of time on because they might change what's running and I dont have any trust or insight into their process - so I might authorize that site 3-4x a year sometimes before I say it can stay.
IMO this service should straight up be made illegal. I love the tagline they have of supposedly "stopping fraud" or "bots", when it's obvious it's just privacy invasive BS that straight up shouldn't exist, least of all as an actual company with customers.
Doing what this demo shows, is clearly a violation of the GDPR if it works the way I assume it does (via fingerprints stored server side).
Maybe Chrome can get away with "the spec says it, sorry advertisers" but I doubt the courts will accept that.
Unpopular opinion: There are no privacy-preserving way for "fraud mitigation".
Either you accept fraud as cost to run business, or do away the privacy. Most business owner don't want the fraudulent user to come back, ever. If we value the privacy of user, we need to harm some business.
[1] The exact figure may depend on which source you use, and there is some indication that ad and tracker blocking may artificially deflate Firefox and friends. https://gs.statcounter.com/browser-market-share [2] https://www.wired.com/story/the-doj-still-wants-google-to-di...
Edit: for clarity, I believe anything with the ability to analyze the user environment via Javascript/etc on major sites is likely fingerprinting regardless. Blocking, environment isolation and spoofing is already necessary to mitigate this.
Guess how they're doing it. It's not cookies. It's also why the GDPR is not a "cookie law" and accepting the prompts but blocking cookies is not really a substitute.
Only reason why we see this movement is because advertisers feels confident about removing third party cookies.
But once anyone gets a creepy fingerprinting system working, the barriers drop, and it becomes cheaper to resell the capability as a library or service.
It may offer some minor benefits in terms of enabling companies that "want to be more ethical than the competition", but that too seems like a long-shot. :p
Which you know, because you say "you can also use CORS to interact with a truly third party site". But now, I invite you to go the rest of the way - what if the third party site isn't Project Gutenburg but `goodreads.com/my-reading-lists`? That is, what if the information that you want to pull into System A from System B should only be available to you and not to anyone on the net?
Now, if you meant "Use OAuth2 in the browser", that's just the original case (you can't authorize if you can't authenticate and it's the ambient authentication that's being stripped when you eliminate third party cookies).
Furthermore, cookies are not a very good way of doing logins. There are other problems with them, including of stealing them if someone else takes over the service, and of difficulty of users knowing what they are if they want to modify or delete specific cookies, and that the server must set the expiry which makes it difficult for end users to control. Methods that are controlled by the end user would be better.
Other methods of authentication can include:
- HTTP basic and digest authentication (which has some of the same problems).
- Two-factor authentication, which has many problems (especially if they are badly implemented).
- HMAC. For things that only require authentication for write access and that are idempotent, it should be safe whether or not the connection is encrypted. A proxy could spy on the operation but can only use it to do the same operation that you had just done, and cannot be used to do any other operation. However, these characteristics are not valid for all systems; e.g. it does not prevent replay and does not prevent spying on what you are doing. For uploading files to a server that are never changed or deleted, if the files are public anyways, and anyone already knows who uploaded them and when, and if nothing else is done with this authentication, then HMAC will work.
- X.509 client certificates. This requires TLS, although many servers already do anyways (although I think that for things that do not require authentication, the TLS should be optional instead). This is secure; if a server obtains a copy of your certificate they cannot use it to impersonate you. Furthermore, X.509 can be used to log in to multiple services without needing an authentication server, and a kind of 2FA is possible if the private key is passworded (and the server you are logging in to will never see the private key or the password). Also, it can be signed by a different issuer certificate that has a different key (the issuer certificate is normally someone else but could also be controlled by yourself as well if you want to); you could store the private key of the issuer certificate in a separate computer not connected to the internet (possibly in addition to being passworded), providing some additional protection if the subject certificate is compromised. There are many other benefits as well.
So the problem for regular humans is the disappearance of features that they've grown used to having without paying any money. Finding a better way to support themselves has proven remarkably difficult.
There are also a billion other ad-supported web sites, each of which make ten people happy. Not a single one of them would be widely mourned, but 5 billion people would each be saddened by one of them.
For a long time I thought pinterest was search spam that no human could possibly want to see, but then I met real people in the world who like it and intentionally visit the site. I bet there are people who like ehow and the rest, too.
They don't care about what happens to the business itself. But they do care about the things the business provides.
If they don't in fact care, then indeed, nothing is lost. But a lot of people will miss a lot of things. Whoever comes up with an alternative that suits the case will make a lot of people happy.
https://privacysandbox.com/news/privacy-sandbox-next-steps/
> Taking all of these factors into consideration, we’ve made the decision to maintain our current approach to offering users third-party cookie choice in Chrome, and will not be rolling out a new standalone prompt for third-party cookies.
It is going to be interesting to see if anti-trust enforcement's manages to separate Google from its financial and practical hold on web standards/browsers.
The opportunity to increase ethical norms of web browsing would be welcome to me.
Well, it doesn't prevent them, but it does make it a little bit harder ...
I don't even understand how being forced to divest Chrome will even help. Once another company owns Chrome and can remove third party cookies, Google gets the same benefit.
So limiting Google's control over browsers will create more competition. More competition on implementations. And also more competition in terms of features and user centric service.
--
Question: Does Google really not gather information from anything but its search engine and first party apps? That would seem financially non-optimal for any advertising funded business.
I would think that sure, they log everything peopel use their search for.
But that they would also find a way to track post-search behavior as well. Google leaving money on the table seems ... unusual if there isn't some self-serving reason they would forgo that.
I am happy to become better informed.
Their long wait to do it is part of why we ended up in a regulatory mess
Firefox, especially in the first versions, permitted much less control on cookies than Mozilla did, but I think it still always allowed disabling third party cookies.
Of course, ad companies scream bloody murder, and the UK market watchdog had to step in so Google wouldn't turn off third party cookies by default.
Idea: domains should be able to publish a text record in their DNS (similarly to SPF record for mail domains) designating other domains which are allowed to peek at their cookies.
Suppose I operate www.example.com. My cookie record could say that foo.com and bar.com may ask for example.com cookies (in addition to example.com, of course). A website from any other domain may not. As the operator of example.com, I can revoke that at any time.
Whenever a page asks for a cookie outside of its domain, the browser will perform a special DNS query for that cookie's domain. If that query fails, or returns data indicating that the page does not have access, then it is denied.
Browsers and browser extensions will be able to use that info to identify shit sites, turning the whitelist around into blacklisting uses, like ad blocking and whatnot.
One simple mechanism would be for the browser to deny the cookie request if the requested domain's cookie DNS record contains more than, say, three affiliated domains. (At the discretion of the browser developer, and user settings.) The proliferation of that sort of config would discourage domains from being overly promiscuous with their tracking cookie access.
Plus, existing cookie control mechanisms don't go away.
Just feeling uncomfortable putting more data into DNS. DNS is not encrypted. DNSSEC is easy to bypass (or break way too often that nobody want to enforce it).
-- but these are not w3c's problem.
If someone hijacks example.com's cookie record, that won't be caught; they just write themselves permission to have their page access example.com's cookies.
The same info could just be hosted by example.com (at some /.well-known path or whatever). The web could generate a lot of hits against that.
The DNS records could be (optionally?) signed. You'd need the SSL key of the domain to check the signature.
Using a SPF record, a domain indicates hosts that are allowed to deliver mail on its behalf (meaning using an envelope sender address from that domain).
I suggest that we do just need to keep third-party cookies but they're explicitly opt-in. That could just be allowing (once) a third party to be present everywhere (like a SSO) and browsers making it known when a third party is accessing data.
I'll just live my life.
Now, down with the rest.
The only distinction is that I can do a decent job of blocking third-party cookies today with my existing solutions like uBlock Origin, but I will probably have a much more difficult time getting around login/paywalls.
You can also easily redirect from your site to some third party tracking site that returns back to your successful login page - and fail the login if the user is blocking the tracking domain. The user then has to choose whether to enable tracking (by not blocking the tracking domain) or not seeing your website at all. Yes the site might lose viewers, but if they weren’t making the site any money, that might be a valid trade off if there’s no alternative.
Not saying I agree with any of this, btw, I hate ads and tracking with a passion - I run various DNS blocking solutions, have ad blockers everywhere possible, etc. Just stating what I believe these sort of sites would and can do.
* "Please wait while we verify that you're not a bot, for which we'll need to associate a unique identifier with your browsing session." (logged in or not)
* The validation needs to do a quick redirection to an external centralized service, because if they can already identify that you're not a bot, you save CPU cycles, and you care a lot about carbon footprint after all.
* Redirect back to the original website, passing the "proof of not-a-bot" somewhere in the URL. This is just a string.
* The website absolutely needs to load the external script `https://proof-validation.example.com/that-unique-string.js` for totally legit purposes obviously related to detecting bot behavior, "somehow".
Half-joking because I don't think this would fly. Or maybe it would, since it's currently trendy to have that PoW on first visit, and users are already used to multiple quick redirections[1] (I don't think they even pay attention to what happens in the URL bar).
But I'm sure we'd get some creative workarounds anyway.
[1]: Easy example: A post on Xitter (original domain) -> Shortened link (different domain) -> Final domain (another different domain). If the person who posted the original link also used a link shortener for tracking clicks, then that's one more redirection.
The only problem is that then the tracking companies have to place more trust on the first party that they're giving them real data.
But they're doing it, actually, see confection.io for example