Hacker News Reader

Comment by fabiospampinato | Hacker News Reader

I'm pretty excited about this for two reasons:

- First of all it makes sense that this feature is provided by the browser itself and they take some responsibility if it doesn't work right.

- Currently the best library for sanitization is probably DOMPurify, and the native Sanitizer API is around 100x faster than DOMPurify, so that would speed up some things dramatically.

I just hope it won't take years for Safari to implement this.

View on HN

> I just hope it won't take years for Safari to implement this.

1000%. Safari likes to talk big about rejecting new APIs to protect security & privacy, but there's a long list of APIs they haven't implemented just like this, that are strictly beneficial for users.

That both Firefox & Chrome have shipped working implementations of this (a serious fix to solve a top 10 OWASP security issue) before Safari has even shown any intent in look at it says a lot imo.

Or in april 2021 they finally decide to implement a date input field with picker, but then half-arse and not support min and max properties [0].

A feature not being supported is clear-cut and workable. This current mess where a feature might be supported, with different parts of the spec available only to Safari 14.1 Bug Sur and up but not 14.1 on Catalina is just tiresome.

[0] https://caniuse.com/input-datetime

No minmax, thanks Apple...

Aren't we overdue for another indexedDB fuck up by the Safari Dev team?

Sshhhh! Don't remind them!

And then iPhone users are stuck due to anticompetitive lock-in.

> Safari likes to talk big about rejecting new APIs to protect security & privacy

Not only that, they restrict existing functionality. For example, all local storage is destroyed if you don’t access a site in seven days. At first blush that makes sense but it means there’s no way to reliably persist data to disk. If you run a web app you more or less have to create a backend, account signups, etc etc. Not only is it a lot of extra work it’s also going to be a huge security vulnerability. The result ends up being entirely counter to Apple’s stated intent.

It seems like that’s one way to prevent lock-in to a single device, or a single browser on that device.

It’s pretty obvious how that is helpful to protect users’ privacy, isn’t it?

Or why would they do it, considering it’s extra work compared to the status quo?

Of course, I absolutely understand how it prevents illegitimate uses of local data storage to violate privacy. My concern is that it also destroys entirely legitimate use cases for local storage and the only way to mitigate that is to open users to a whole new class of security vulnerability they can do very little to protect themselves from.

I believe the criteria are more complex than just “7 days”. There’s something about AI or ML in the Safari “experiments” settings, and IIRC first- vs. third-party data is handled differently, and data may also be protected for more than a week if you previously had regular interactions with the domain.

That uncertainty is still a blocker for many apps.

Reply on news.ycombinator.com