- dark mode
- improved tracking restrictions
- Payment Request API
- support for VP8 with WebRTC
- updated DRM
- streaming improvements
- Intersection Observer API
- API for native share dialogs
- input type="color"
Please. This is my biggest gripe during web development. I hate the fact that I have to add a bloated bunch of JS to my site just to get a date picker.
Unless the hardware supports it Apple will probably shy away. In this case, the WebRTC standard calls for VP8 (even though h.264 is becoming more common).
8 years after it was implemented in Firefox and 7 years after IE and Chrome. It is far from a new thing, but it is great to see Safari catching up with the web standards.
There are a number of hacks to remediate this such as using a div with overflow scroll which encapsulates the iframe, or using an absolute positioned wrapper on the contents of the iframe.
Everything is like this with Safari, the IntersectionObserver was implemented 2 years ago in Firefox, the input color was implemented 5 years ago.
Safari is always lagging far behind, and that's just the list of technology here, it's difficult to list all the nonsense tricks you have to do to make your website specifically work on Safari when it works on just about everything else by default. Personally I spend about the same time on Safari support as IE11 support. Has Apple gave up on Safari?
I tried to implement a search suggestion system with a datalist a few weeks ago only to find out that it was not stylable, there were zero events I could catch to find out an option was clicked/chosen, and there is no identifier possible for choices (so a display string is the value, no ID possible = impossible to localize or use for non-human-input values)
you can type in select lists, but it search from the beginning of each select-string (no "17" to get to "2017") and if you type too slow you reset your search query.
In Mac 12.1.1 the data-list seems to work that way, (based on the example in this article), but the color picker seems busted (the color remains the same default, no matter what is chosen interactively).
Where is the U2F/FIDO support? The Mac could be using the T2/Secure Enclave to differentiate massively here - same goes for the iPhone and iOS. (The Pixelbook just enabled built in U2F hardware behind a shell flag.)
TOTP is still vulnerable to phishing. Why Apple has been ignoring this when their biometric products are such a great fit for it is a mystery to me.
Despite a lot of insistent critics that say otherwise, I believe that one of the world’s richest companies can walk and chew gum at the same time - or just pay someone else to do it. It’s not really an issue of resource constraints; the work could easily happen in parallel.
I just wish someone at Apple cared enough about unfucking web authentication.
There are a ton of reasons why Apple prioritizes what it does, not least of which is available resources. We don't even know what dependencies they may have between their product teams. It's not like Apple is this all seeing entity that commands its team to do as it wishes, at least not at the micro level.
Anyone in the ad-tech industry that can comment on the ITP changes? It's the thing I look forward to the most.
>Updates to Intelligent Tracking Prevention add new restrictions to cookies, further reducing the ability of hidden third parties to track users across websites they visit. To do that, support for partitioned cookies was removed for domains Intelligent Tracking Prevention identifies as having cross-site tracking capabilities. Going a step further, Intelligent Tracking Prevention now also limits long-term tracking for JavaScript first-party cookies.
It further entrenches Facebook and Google's monopoly on adtech and solves nothing against the companies that people worry about most (and ironically give up the most data too). It also does nothing to stop the wild-west of mobile app tracking.
The ideal solution would be to offer up the device's Advertising ID to the browser, just like it is available to mobile apps. That would remove all the tracking pixels and workarounds and improve privacy as the user can easily reset their ID whenever they want to.
They have 1st party connections to their users through both apps and websites and will always know who the person is. ITP does nothing to stop them. Amazon will be the 3rd major adtech company soon and ISPs will also be unaffected as they're starting to build up more adtech businesses themselves.
ITP is mostly a PR play for Apple's "privacy" marketing push that again hurts publishers and smaller independent internet companies.
That means nothing in practice. These companies have the data, reach, and 1st party connection for those cookies to be constantly replaced and augmented with plenty of other signals.
Since this is downvoted, I'll be extra clear: these companies have websites and network traffic that billions of people use directly which means they can serve HTTP cookies and other signals which are not touched at all by ITP.
Are you being sarcastic? Or seriously suggesting the billions of users of Google and Facebook should just stop using them? If it was that easy then why all this trouble with ITP in the first place?
The problem is you don't speak for the billions of people use various Facebook and Google services to live their lives without easy alternatives. When someone is using Gmail to run their small business or using Facebook to keep in touch with their distant relatives, I'm sure saying "what's so hard" is all it takes to get them to see the error of their ways.
I don't use those sites either, but a rather large fraction of websites include javascript from Google. You can try to avoid those sites, too, but it's a lesser Internet.
The point is that mobile apps are 1000x more intrusive than anything on the web (which was always designed for anonymous users).
Apple does not do anything to stop mobile apps tracking even with the app store review and the ability to scan them both on submission and as they're running in the OS. Mobile apps are 90% of the source of adfraud and privacy issues on iOS.
Meanwhile Mobile Safari (even without ITP) has caused numerous problems with apps trying to offer webviews for content while trying to keep users signed in. There are numerous effective improvements to be made instead of messing with cookies.
After discovering mitmproxy, I checked out various apps on my Macbook. Found plenty that at least phoned home to Google Analytics on boot. Some even phoned on every action/keypress.
Not sure why HN has such a hard-on for native/mobile apps. You get performance at the expense of basically everything else. There's no dev toolbar. No extension system. No customization. No uBlock. You take it all or nothing. And you need intrusive tools like mitmproxy or Little Snitch just to get insight into their network traffic.
Native apps often (not always) get you not just performance, but also efficiency, no annoying browser chrome, adherence to platform UI conventions, and utilization of platform-specific features (no lowest common denominator syndrome).
Electron apps can get rid of the browser chrome at least, but it comes with the cost of a redundant copy of Chromium for each app, which is worse than running in-browser in terms of resource consumption.
Web apps would be great if they could deliver the things mentioned in the first paragraph on top of their security/privacy benefits, but I don’t see that happening any time soon.
Anything that's using a web view is affected, so this definitely affects ad tracking in mobile apps like Instagram. It shouldn't affect the apps themselves unless they start making other workarounds to persist identifiers for their advertisers, which they almost certainly will do.
That’s just the author of that post not having thought through the security model. <a ping> doesn’t do anything which isn’t already commonplace – it just does it without performance and reliability impacts. Without that feature, everyone still gets tracked but they have to wait for often-buggy JavaScript or server redirects to complete before navigating.
Interesting, but given it’s a link already controlled by the website I don’t see the difference between ping and simply linking to a tracking URL like google already does. This just allows websites to retain proper semantics.
document.cookie is also already controlled by the website, but due to everyone <script src>'ing 3rd party trackers like GA it looks like they felt the need to limit this api. So why remove the possibility for blocking the same scripts from doing foreach('a').attr('ping','3rdpartytracker/uniqueId/'+this.href)?
Nothing's stopping those scripts today from converting all links to bouncing through a redirect domain for tracking, and yet scripts aren't doing that.
That has UX implications, with the mouseover statusbar link target popup and the right/middle mouse click to copy-url/open-in-new-tab features making it much more obvious.
Okay, so imagine it’s adding click event handlers which use XHR/Beacon to avoid the user-visible rewriting. That’s the same impact but everything is slower and you have edge cases where navigation fails with no user feedback at all.
I'm in analytics, not ad tech, though they are pretty well coupled.
This is a pretty concerning move. One week is super aggressive. There are several ways around their restrictions, but I really wish I didn't have to consider them.
Long story short, if you reflect a client-side cookie back from the server-side (by having the host site set up a CNAME to your collection servers), then it sets an HttpOnly cookie that will last as long as you tell it.
This technique is pretty effective at also skirting adblockers, which is why I really wish it weren't the easiest solution, as my company has been very conscious of not trying to work around ad blockers and the intent of web site visitors.
This is going to surprise and confuse a lot of customers in the analytics world, but ultimately, they'll adapt and we'll make do.
You've posted the same thing dozens of times and I've replied to them before. Advertising as a concept is different from online ads as an execution. The latter is bad but there is no replacement for advertising based business models.
Good for you if you pay for the news but you don't represent the billions of people on the internet and what they want, what they can afford, and how they value it is well known. Advertising isn't going anywhere.
I've got nothing to hide. This is my real name. Yes I'm in marketing, I'm known in the industry, I wrote about ad blocking [1], built an adblocker, spent 6 figures to test alternative payments [2], am part of every initiative to make ads better [3], and have spoken with senators to push for regulation. Does that work as a disclaimer?
But what does business interest have to do with discussing advertising as a concept vs implementation? We can discuss highly technical topics with nuance but when it comes to ads, why is there such a visceral and emotional reaction?
And this why ads are a problem. From your own article.
Options include continuously changing domain names and server-side ad rendering.
People clearly have expressed their intent not to want ads, yet you want to have systems to force it on them. If people have signaled that they don’t want to ads, do you really think it is your target market. Who exactly is it serving?
Ads, especially on mobile with limited real estate, slide shows, etc makes web pages unreadable. I specifically don’t use the Facebook app or any other app that doesn’t use the SafariViewController (which supports content blockers) to display external links.
Btw, no I didn’t search for your name on the internet. I just went to your HN profile. I thought anyone who so vehemently defended the adtech business must have a business interest in it.
Most content producers want nothing more than to diversify from a dependency on ads so I knew it didn’t come from anyone on the content side.
That's still mixing up concept vs implementation. I described 4 reasons why adblockers are used in the first place. You won't find anyone else in adtech who's criticized the the formats and experience becoming too intrusive but it's not something that gets solved easily, and a big part of the problem is because people outside the industry are not willing to cooperate.
As far users: It's not about wanting ads, it's about wanting content. The cost is paid for by ads. People make that choice willingly, and that choice is rarely relevant to any product's target customer profile, but the process is serving both users and advertisers by facilitating the trade in attention vs content. Sure content producers want direct payments, and the rise of patreon and subscriptions shows success, but the scale and reach of that is inherently limited. Very few people can afford to pay for all the varied content from so many different sources that they consume daily. That's the fundamental problem.
Ok? That's not an argument. We're just going in circles.
Bundling is just a stage in the cycle of payments that every medium goes through every few years and doesn't change the fact that most content still is, and always has been, paid for by advertising.
That makes no sense. Marketing is about efficiently matching customers with products filling their needs and wants. Advertising is the communication that makes this system work and relevancy is a core factor.
Irrelevant ads only waste time and money and work against both sides.
It isn't. Marketing and advertising in particular is about making people buy the product that the company paying for the advertising wants to sell. It uses lies and emotional manipulation to make people think that they need that product. Helping customers fulfill their needs and wants is not helpful when these needs and wants would not even exist without ads.
This is particularly obvious for ads for stuff like coke: Everyone knows coke exists. Ads for it do not inform at all, they only manipulate.
If ads were useful to the customer, then there would be no need to embed them with useful services, let alone to force customers to expose themselves to them by turning of their ad blockers. It would not make sense to give customers a choice between paying for a given service or suffering from ads: Those are signs that the value of ads for customers is negative. If it were positive, you could even charge extra for them.
Despite being a very bad method of informing customers, ads might be defensible if they were the only one. But they aren't. Classifieds may technically be ads, but they differ fundamentally from others in that customers specifically seek them out. That indicates that customers do get value from them.
Another suitable method of informing customers are newspapers and magazines, especially specialized magazines and ones like Consumer Reports. Their interests are aligned with the customer because it's the customer who pays them.
Admittedly, there is a problem with those publications: Most of them also contain ads. That means advertisers can influence their reporting with the threat, spoken or unspoken, to no longer advertise in them. This is another way ads make products worse and obviously not an argument in their favor.
That's a conflation of several different things and redefining marketing from the actual definition to be what you want doesn't make a good argument. Lying in ads is illegal and "manipulation" is just another word for influence, the same as when you recommend something to your friend. Whether you trust a brand or not is no different than whether you trust a friend which is why we have branding and customer loyalty in the first place.
Advertising is communication and has no inherent usefulness; the value is in the outcome. The user isn't suffering, they're choosing a way to convert attention to currency as a way of paying for the content they want. It's a choice they willing make and having the option to transact that way is a net positive for both sides.
It's not novel, it's been used for centuries. The industry is a lot smarter than you think. But people don't value news and can't pay anywhere near enough compared to what they consume.
Ads allow people to read what they want, when they want, for how much they want, regardless of publisher name or how much wealth they personally have.
It's working out fine. 90% of the content and services on the internet is paid for by ads.
There's also cycles. TV went through OTA to cable bundles to a-la-carte streaming and is now heading back to ads and bundles as people have reached their limit on payments. Music is in the bundle stage. New formats like podcasts are still in the early ad stage. Online publishers are at the peak of the direct payments stage and heading to news bundles next, which you mentioned yourself.
Regardless of the cycle, ads pay for the most and are almost always part of the deal because it's incredibly hard to sustain content production with rising costs at any price that consumers actually want to pay.
Adblockers. It is technical hammer that breaks the content-for-ads trade-off.
If there was an extension that you can install with 1-click that lets you order from Amazon.com for free, would people not use it? Does that suddenly mean that Amazon is no longer valid as a business?
These companies will either use technical countermeasures, or switch to different revenue models, or go out of business. But individual producers don't change the fact that most content is paid for by ads, powered by 2 of the biggest companies on the planet.
And nothing of value will be lost. If a business can’t survive market realities, so be it.
On the other hand, there is always the “1000 true fans” way of making money. Keep your expenses down and write content a few people are willing to pay for.
Ben Thompson over at Stratechery has well over 2000 subscribers the last time he gave out numbers, now its closer to 4000 probably. They pay him $100 a year for one article delivered 4 or 5 days a week including a free article.
John Grubsr over at Daring Firebsll is able to charge $6500 a week for a sponsorship- one article on the website and in the RSS feed at the beginning of the week and one thank you post at the end of the week.
No horrible privacy invasive ads, no ad networks, etc. It is basically an Apple centric blog he’s been building since 2002.
When Google killed Reader, he lost half of his readers but he was still able to charge his same rates. Advertisers were able to reach a desirable demographic.
"We found that, on an iPhone 7 Plus in laboratory conditions, the use of H.264 on a 720p video call increases the battery life by up to an hour compared to VP8."
That said, they make their own chips. They could certainly add it to the iPhone n+1 if they were so inclined.
Intel CPUs have hardware decoding support for VP8 since Broadwell, but Apple's Macs don't take advantage of that. So it seems Apple has more reasons not to support the (Google backed) codec apart from hardware decoding support.
and while they don't update chips, they could just allow the user to give their batteries to see the content if they choose to. So condescending to limit user agency like that.
99.9% of users wouldn't know why their phone battery is dying more quickly. They'd just complain that the latest update (or whatever) made their phone worse.
I guess they could have some sort of pop up saying "The website you're visiting is using a technology that uses more power on your phone" but that seems like a pretty crappy compromise.
Of course we will, Supporting H.264 long enough it will also become a free codec. Which is ~2027. Considering x264 is still one of the best if not the best in Medium to High Bitrate encode, this is something worth looking forward to.
And MPEG are already working on new codec based on H.264 that will be completely royalty free.
If you are referring to AV1, it's still a year or two away (probably) from being supported in hardware and it's too complex for CPU encoding in real-time. H.265 is supported in Apple hardware, but not part of the WebRTC spec or supported by browsers.
It depends on the encoder though. The AOM encoder is still quite slow, but Intel's SVT-AV1 encoder (https://github.com/OpenVisualCloud/SVT-AV1) is achieving 20 frames a second:
You always have to consider encode time versus image quality versus bandwidth. Twitch is using NGCodec's FPGA based VP9 encoders to live stream with the same image quality at a lower bitrate than H.264 can achieve:
Great news for PWAs buried in the release notes: “Updated the behavior of websites saved to the home screen on iOS to pause in the background instead of relaunching each time.”
What saddens me[1] is how horribly hopeless Safari's Developer Tools are. They are basically unusable at this point. Every month Chrome adds more capabilities to their dev tools than Safari in a whole year.
[1] It's been saddening (is this a word?) me for over six years now. Safari's dev tools were best in class, and then they never really improved. The UI was updated once or twice, each time making the UX considerably worse. People may complain about how Apple doesn't care about pro market anymore, but the writing has been on the wall for some time now, and the first canary in the coal mine was Safari.
BTW. If you're interested, go to Develop -> Enter responsive mode. And then go Develop -> Show web inspector. Good luck working with the unzoomable screen. The first time I saw it, I had to go outside and walk for a bit.
The DevTools have actually improved considerably. It seemed to be the major focus in several recent releases, at least by the length of the respective sections in change notes.
I have changed from Chrome-only development to using both, since they have individual strengths. Safari has pretty good tools in the battery and performance profiling, for example.
> If you're interested, go to Develop -> Enter responsive mode. And then go Develop -> Show web inspector. Good luck working with the unzoomable screen. The first time I saw it, I had to go outside and walk for a bit.
I think they're pointing out that when the web console is docked on the bottom (default), the responsive viewport is shrunk since it's scaled by window.innerHeight with no way (afaict) to zoom independently. At least I couldn't figure out how.
I think I found a bug: docking the web console vertically while in responsive mode hides the top row of controls. For example there's no button to dock horizontally. (Edit: actually this was just fixed after updating Safari)
I think I found a bug: docking the web console vertically while in responsive mode hides the top row of controls. For example there's no button to dock horizontally.
Yep. I ran into this a couple of weeks ago. I thought it was something wonky with my machine and rebooted to make sure.
My primary audiences on a couple of projects are IE11 and Safari. Sucks to be me.
If you enter the responsive design pseudo-device simulator mode, you are automatically scaled if the virtual viewport is bigger than Safari's master viewport. Which, yeah, slightly annoying, but it's never caused me to rage walk. (Generally I'm using this to look at a teeeeeny little iPhone SE viewport.)
It's not going to make me storm out of the room but juggling multiple browser windows (and really, multiple windows of any app) has never been palatable to me.
The annoying dance of alt-tab alt-tilde over and over, god forbid you have more than one dev tool window open or another browser window like Postman open.
You should simply be able to scale a viewport independently of the chrome.
Or get a 4K monitor. With one it seems absurd to have dev tools docked. Why would you want to do that when you can see 2160 vertical pixels (minus chrome)? Always good to know if that footer is sticky.
Unless I am not seeing a polyfill inclusion, at least some of these are supported in Firefox already (66.0.2) - Color Input and Data Lists, in particular.
(Not trying to dis Webkit/Safari here - just saying that the "Can I Use?" list grows desirably longer.)
I wonder if Microsoft's move to Chromium for the Edge browser will push Apple to move more quickly? Safari will a more obvious outlier if the other two major browsers support technology X and Apple doesn't. Currently the waters are a bit muddy with Edge not properly supporting a lot of the latest technologies (like WebRTC).
> The Payment Request API has been updated with granular errors, support for default addresses and contacts configured in Wallet and Apple Pay settings, and special field support for Japan.
What is "special field support for Japan"? I cannot find any reference to this in the specification or on Google.
It allows merchants to require a phonetic spelling of the recipient's name be returned as part of the shipping address. This is a feature specific to the Apple Pay payment method, and is implemented through Payment Request's various payment method extension points (e.g., PaymentMethodData.data, PaymentResponse.details).
It's incredible and pathetic how color-handling has regressed since the early '90s.
Windows 3.1 through XP had system-wide, user-configurable color schemes. You could set up a non-inverse (what today is being touted as "dark mode") color scheme in a few minutes and all applications would honor it. You could do the same in Unix GUIs. Only the Mac forced its glaring inverse-video scheme on you 24/7.
Now, inexplicably, Windows has ELIMINATED the ability to set up a global color scheme, and Apple has delivered this half-assed, hard-coded workaround after 40 years. This after Apple was challenged at WWDC in the early 2000s for their lack of color schemes, and feigned total ignorance that anyone would want them.
