There may be room for more improvement here but be aware what the POCs illustrate is not an active vulnerability any more.
In addition, we don't believe this channel was ever exploited in the wild.
(If anyone is aware of other issues in this area, I encourage you to practice responsible disclosure and report to Apple or to the WebKit project.)
Well, WebKit came from Apple’s work on KHTML. So Safari, Chrome, Edge ...
”KHTML and KJS were adopted by Apple in 2002 for use in the Safari web browser. Apple publishes the source code for their fork of the KHTML engine, called WebKit. In 2013, Google began development on a fork of WebKit, called Blink.”
That’s not that long ago in browser families, and 2002 - 2013 is 11 years of investment in web tech that now everyone else built on. And they didn’t stop investing.
Some of those investments:
- It’s mostly been the least battery hungry modern browser (by a long shot) on the most wished for dev laptop, and in many cases, the highest performance.
- The bookmark and tab sync across devices is seamlessly slick. I regularly end up maxed on tabs (it’s in the 100s of tabs open at once) and can access any / all of them across all devices sharing iCloud account. Also appreciate that across all kinds of devices, you can save all open tabs to a folder of tabs, then close all tabs, and immediate get at those 300 tabs in the bookmarks from another machine. All those bookmarks are searchable too. None of this slows it down.
- Built in reader mode works beautifully. Reading List is there too.
- Saving a web page to file can save clean reader views into full length PDFs. They’re amazing!
- Interacts with keychain, essentially has LastPass “built in” if you let it store passwords on your keychain.
- While I miss UBlock Origin, ad blockers like 1BlockerX work great across iPad, iPhone, and MacOS. (See also AdGuard for Safari.)
- ITP performs better than one would expect for something you don’t think about at all, while not breaking most banks, which I appreciate.
- Safari never kills my iPad, iPhone, or Mac. Once in a blue moon a terrible site makes me ‘eject’ Safari from running apps on iOS. Launch it again, and all your tabs etc. are fine.
There’s a lot to like, except it’s not super tweakable, or basically “it’s not Chrome”. Even there, most devs or tech geeks who grump at Safari and reach for Chrome, have no idea of the lineage.
Doesn’t seem fair to call it under-invested in.
Apple's OSS work tends feel well-made (I use CUPS on Devuan, they own that), but they are not and will never be "The One True Web Tech Makers".
Still, they're the biggest ones on the market as of today, if you count their offspring, Blink.
Basically Safari keeps track of which domains are being requested in a 3rd party context (i.e. I load example.com in my browser and the page loads the facebook sdk - Safari increments a counter for facebook by 1). Once a given domain reaches 3 hits, Safari will strip cookies and some other data in 3rd party requests to that domain.
The problem is that advertisers can use this to fingerprint users: register arbitrary domains, make 3rd party requests to them, and detect whether or not that request is having data stripped. Each domain is an additional "bit" of data.
This is similar to "HSTS Cookies"  and also to issues with Chrome's XSS auditor, which is why it was removed .
Better still, when you see a split discussion, email email@example.com so we can merge them. We'll make sure your comment ends up in the winning thread.
The link could die, the text at the link could change, or the comment at the link could be deleted. Not to mention a comment section full of links is ugly and unreadable.
StackOverflow has the exact opposite approach because they don’t want their site riddled with dead links.
How many people will care enough to send an email to have a comment merger? That really isn’t a solution to whatever “problem” this is.
A good privacy design needs to confront this issue directly. Sometimes there's nothing to be done. I think in some cases it's mathematically unsolvable (cf. Cynthia Dwork's paper on Differential Privacy). But an explicit consideration can at least surface some trade-offs. The more fine-grained and selective your redactions, the more information they reveal.
But: (1) only a tiny teeny little bit, and (2) the gains in password complexity are probably worth a lot more.
Imagine you have a site that allows numeric PINs between 4 and 6 digits. And another site that requires exactly 6 digits.
Technically, the search space is larger for the first site. An attacker would have 1,110,000 possible codes to check, whereas the 2nd site has 1,000,000. But ensuring that all users are in the 1,000,000 search space is worth it to prevent some users' 4-digit PINs being cracked.
Technically, there are 1556820866911379157697368408533647424628560378091278400 possibilities for a given password from the first site, and only 1553740989173808677121103544993503115087947728215015424 for the second site. That's only 0.2% fewer total passwords. However, consider that the typical user's password is probably 6-8 characters and contains only lowercase letters; that means that most users from the first website have only 217167790528 possibilities, while users from the second website--even assuming they only go the bare minimum of 6 lowercase characters + one special character + one number--have 345985669120 password possibilities, which is about 60% more. And that's with the artificial base64 limitation; if you open it up to the full complement of 30 special characters it's significantly more.
> Your password must be exactly 6 characters
> The first character must be one of: a, b, c, d
> The second character must be one of: !@#$
"We used known Safari functionality to provide features that signed-in Google users had enabled. It’s important to stress that these advertising cookies do not collect personal information."
and bypassing IE third party cookie protection:
"impractical to comply with Microsoft’s request while providing modern web functionality." Google says complying with tracking protection is Impractical!
“hiding” vs “blending in”(making me look identical to countless others - maybe even randomizing who I look like in a smart way).
I wonder if any subject area experts reading this thread would be willing to share a summary of their knowledge and thoughts here.
Just a thought:
I think the route Mozilla is taking is where the industry is heading. More open-source/transparency means more privacy protections for the user. If we get to the point where every browser has built in security features, fingerprinting becomes more of a challenge.
Websites themselves could provide the functionality of a data broker. I am perfectly okay if I get suggested products by a company that already has my data.
In my honest opinion, the current landscape is more than hostile towards the average user and needs immediate course correction.
But then, here's the thing. My other personas are similarly focused, but on other stuff. And they don't use English.
A determined global adversary could link them through traffic analysis. But it's a big Internet, and I don't make it easy.
>Chrome plans to more aggressively restrict fingerprinting across the web. One way in which we’ll be doing this is reducing the ways in which browsers can be passively fingerprinted, so that we can detect and intervene against active fingerprinting efforts as they happen. 
This will include things like restricting the volume of Browser API checks allowed, etc, to reduce the number of bits that can be used in a fingerprint.
They'll only really block fingerprinting in their browser when they have no use for it.
Can you show me that's true? If it is, that's fairly interesting.
I understand that privacy engineering is very hard and sometime can get not very obvious with implicit statistical dependency chains, but this kind of direct problem could (or should?) be caught in an early stage of design. Anyway, ITP is all about privacy and deserves attentions from dedicated privacy engineers.