Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Safari Privacy Security IT Technology

Safari 14 Removes Flash, Gets Support for Breach Alerts, HTTP/3, and WebP (zdnet.com) 54

Posted by msmash from the up-next dept.
Safari 14, scheduled to be released later this fall with iOS 14 and macOS 11, is a release that is packed choke-full with features. From a report: The biggest and most important of the new additions is support for WebExtensions, a technology for creating browser extensions. What this means for Safari users is that starting this fall, they'll see a huge influx of new Safari extensions as add-on developers are expected to port their existing Chrome and Firefox extensions to work on Apple's browser as well. Apple said that, for now, WebExtensions will only be available for Safari on macOS.

Safari 14 is also an end of an era, as this will be the first version of Safari that won't support Adobe Flash Player content. But while old stuff is being removed, new stuff is also being added. One of the new technologies added to Safari is support for HTTP/3, a new web standard that will make loading websites faster and safer. Another important addition in Safari is support for WebP, a lightweight image format that has been gaining widespread adoption across the internet. The format, created by Google, serves as an alternative to the older JPEG format, and Safari has been the last browser to add support for it. [...] But Safari hasn't been lagging behind other browsers just in terms of HTTP/3 and WebP support. Apple has also added support for another cool feature, namely breach alerts, already present in both Chrome and Firefox. Starting this fall, Apple says that Safari 14 will scan a user's locally-stored passwords and show a prompt if one or more of the user's credentials are present in publicly available lists of breached accounts.
This discussion has been archived. No new comments can be posted.

Safari 14 Removes Flash, Gets Support for Breach Alerts, HTTP/3, and WebP More

Safari 14 Removes Flash, Gets Support for Breach Alerts, HTTP/3, and WebP

Comments Filter:

  • Choke-full is more better? (Score:5, Funny)

    by Yo,dog! ( 1819436 ) on Wednesday June 24, 2020 @02:48PM (#60223358)
    If the update was chock-full with features that would be amazing, but I guess it's more than amazing, because it's choke-full.

  • My copy of Safari hasn't been able to play Flash content in years. But I do feel sorry for the half-dozen or so people this change impacts.

  • Just like HTTP/2, HTTP/3 is a protocol by Google, for Google. If you are not a big company like Google, you won't benefit much from it. The web was simple, now it will be complex and ugly. Many ordinary websites don't benefit from all the features in HTTP/2 or 3. What Google should have done, is leave HTTP alone and create their own protocol via WebSockets. They could even have a more optimized protocol for all their Google webservices.

    Yes, HTTP/1 was old and could use an update. But it could have been much

    • Re: (Score:1)

      by Anonymous Coward
      Dude I know it's asking a lot of people to read the article but the explanation is literally in the summary. Any protocol over TCP has inherent limitations that's why they made a new one.

    • Re:By Google, for Google. (Score:5, Interesting)

      by slack_justyb ( 862874 ) on Wednesday June 24, 2020 @03:47PM (#60223618)

      Just like HTTP/2, HTTP/3 is a protocol by Google, for Google. If you are not a big company like Google, you won't benefit much from it.

      Oh give me a freaking break. Keeping with http/1 made zero sense. Opening tcp connections is expensive. There's a 3-way for each tcp. Now you know what, back in the day t/tcp would have fixed that. Now t/tcp didn't address anything in terms of security but then tcp tfo was invented, except it doesn't work, because it requires all the routers in the chain to understand it and things like nat break it. So understandably you can't make tcp cheap at the moment because of everyone in the chain going from source to remote, someone always breaks the tfo bit in tcp, and then you have to re-transmit, which means no one turns it on, because there's always someone who will break it, because everyone turns it off, because someone will break it, because everyone turns it off, because (inf. loop). And if you are using nat, which every home pretty much does, then it doesn't even matter. That's why the whole carrier grade nat thing was a thing. A breath of hope to have fast open tcp built in, but then it would have required all the home users to upgrade, which they won't, so then it would have broken that, so there wasn't any reason to have tfo in cg-nat. But everyone wanted it, but no one wanted to do the things required. (and that's the short end of that story) So the only thing that you can do to increase the parallelism of http is to somehow break up into multiple requests and send it down the stream. Now you can parallel that into multiple tcp connections like http/1.1 did but then we all found out how utterly slow that was, hence why people were inventing things like spdy and what not which eventually became http/2.

      What Google should have done, is leave HTTP alone and create their own protocol via WebSockets

      ws solves nothing in terms of the problem of resource allocation. You need the javascript/css/html to build the ws or at the very least you need some basic html and js to have a bare dom and from there ws the rest of the resource. That means you still need at the base the first get calls to:

      GET /
      ...
      GET /js
      ...
      GET /js/module1
      GET /js/module2
      :
      :
      (depending on modules)
      ...
      WS (finally, but now your app gets to manage conns, as opposed to the stack)

      You still need a method to bring those initial request in AND you've added a complexity layer by now requiring that to run over a ws connection.

      Additionally, you keep saying that this is "for Google services" and I'm not sure if you've checked recently, but Google, Facebook, Twitter, and so on are all embedded in a lot of sites that are not Google, Facebook, Twitter, and so on. So those services and getting their resources to the client quickly affects non-Google/Facebook/Twitter sites. You are out of your mind if you think outside sites are going to sit there and muck with a javascript wrapper to handle the ws channels. Bad enough as is, but the entire point of a layered approach is so that the layer above doesn't worry about the layer below. web sockets gives you the power to control the socket, but it also gives you the power to control the socket. Not a lot of site designers want to get into socket management, and then you'd have socket management libraries written in javascript, which would need to http their modules, and now you've added to the original problem of needing more parallel http for the socket management libs before the init ws can be made.

      But it could have been much more simple

      Yeah, they tired that in http/1.1, it didn't work. The simple solution requires some letting go of some of the old stuff and people have massive issues letting go of what they know. That was the thing, http/2 didn

      • Thanks Slashdot! I'm ready for my (-1) Offtopic x5,000,000 now.

        You got your "Score:5, Interesting" rating so you can chill on the passive aggressive whining bit. ;-)

        If that was supposed to be sarcasm...ok, sure, whatever. In any case, thanks for taking the time and effort for explaining that for the benefit of all.

    • Re: (Score:1)

      by Anonymous Coward
      People who don't know what they're talking about shouldn't be telling others how things should be done. e.g.: HTTP/1 was updated by HTTP/1.1. It was HTTP/1.1 that added request pipelining. Amongst other things HTTP/1.1 also added persistent connections (Keep Alive); Range requests (partial downloads, resume downloads); and Extensible Authentication.

  • I was using it you bastard dogs.

  • No PWA compatibility upgrades (Score:4, Insightful)

    by Merk42 ( 1906718 ) on Wednesday June 24, 2020 @03:19PM (#60223488)
    Need to keep that sweet sweet App Store revenue flowing after all.

  • I know this won't affect a lot of people, but webp has been a real nuisance for my work. I often have to acquire images from sites, and increasingly they're coming as wepb, which means each has to be converted back to JPG or PNG. (Not just JPG is converted.)

    I kind of feel like this is 'breaking the web', adding in uncommon formats. And the stupid thing is some of the sites doing this won't even accept webp images. (Shopify for example is now converting images to webp, and if you download from your own store

    • Apple switching to HEIC 3 years ago is considerably more annoying when practically nothing supports it even now. Way more annoying for most people workflows. At least WebP is supported by a lot of the apps I use. Due to patents the situation with HEIC is not likely to improve much in the future.

      • you can turn off HEIC in your settings (Score:1)

        by Anonymous Coward
        It's one of the 10 things any sensible person does when they get an iPhone. Turn off Amber alerts, set your do not disturb hours, turn off HEIC, etc. Yeah it bites people who don't know any better (like those kids who flunked their standardized exams because they were required to send in cell phone photos to prove they weren't cheating ... only to find their HEIC photos were rejected) but at least you can turn that shit off.

    • Re: (Score:3)

      by Merk42 ( 1906718 )
      What are you trying to use the WebP image in after you save it? That's the problem. Whatever software that is, needs to up its game.

      With Safari, WebP will be supported in every actively developed browser, so that's hardly "uncommon".

    • Then the solution is simple: Start supporting WebP yourself.

      WebP is gaining support because it works, and it works well. I've verified this myself, conducting my own testing. WebP on lossless mode wipe the floor with PNG, even after that PNG has been through optipng and advpng. The files are smaller, which means they load faster. On lossy mode, the advantage over JPEG is less, but it's still there. You can get a smaller file for the same quality, as measured by dssim. Plus it supports transparency, which JP

  • Most web sites I use no longer require Flash, but one does: the US NOAA Weather Service [weather.gov] local weather radar and image loops. While static images can be viewed without Flash, animations and zoom in/out require it. They've known for years that The End Is Coming, but now that it's Almost Here there's still no sign of change, even in testing. They spent a lot of time and public effort last year updating visual and branding aspects of their web site, but not the very useful radar and image animations. Grrrrr....

    • Re: (Score:1)

      by grosh ( 617934 )
      Try their aviation site (https://www.aviationweather.gov/radar). It doesn't use Flash.

      • Try their aviation site (https://www.aviationweather.gov/radar). It doesn't use Flash.

        Thanks muchly for that!

        I can confirm the RADAR loops work just fine in Safari on my iPhone; which of course knows nothing of flash player...

    • Adobe is killing Flash on 12/31/2020. It's time for NOAA to upgrade or they'll be no longer accessible at the end of the year.
  • Goodbye, Flash. Don't let the door hit your ass on the way out. Flash sucked from its inception and should have gone away 20 years ago.

  • In all honest, does ANYONE care about Safari anymore?

    • Re: (Score:2)

      by tsa ( 15680 )

      Many many Many people run Safari on iOS.

      • Though Safari never supported Flash in iOS so I would assume he means "who uses Safari as a desktop browser".

        On the other hand Safari is the default browser and more power efficient than the rest so I would assume that a lot of macOS users go with Safari.

      • Safari (iOS and Desktop both) is in the position that Internet Explorer 8 used to be in: still used by a small yet non-ignorable *minority* of the Internet and acting as a brake on browser innovation. (Change My Mind.)

  • This is pretty much the reason I don't use Safari on MacOS.
    My primary computer for creating stuff is a 10 year old MacPro 5.1 (the old cheesegrater), it's locked on Mojave. Short of messing about patching the OS with some third party solution (and the risks associated with it), it means I'll never get the latest Safari.

    So, yeah, Firefox it is.

  • The iPhone software is so behind Android it is embarrassing. The lack of WebP is a disgrace especially for devices like the iPhone which come with low storage and only 4g

Slashdot Top Deals

Some people manage by the book, even though they don't know who wrote the book or even what book.

Close