Hey there @ThimPress!
Chrome 68 will begin labeling all HTTP sites as “Not secure” in the address bar ==> making the Preview.ThemeForest.Net site to be labeled as Not Secure
This is something we have been quite aware of as many members of the engineering team run Google Chromium or Canary builds and have been following this movement with great anticipation - not just for us but for security across the web.
Please fix this by adding SSL to preview.themeforest.net .
Unfortunately, the HTTP only previews have been a thorn in our side since before we migrated to HTTPS everywhere and it hasn’t got any easier in the recent months when this was revisited. In the months leading up to this HTTP deprecation notice, we’ve had quite a few discussions on how we can mitigate this issue but I’m afraid we still don’t have a solid plan for addressing this for a number of reasons.
We can’t force HTTPS for every live preview.
There are still a bunch of authors that don’t have HTTPS enabled previews and enforcing HTTPS for this preview would result in the client getting mixed content warnings (bad news for SEO fans!).
We can’t conditionally (sensibly) enable HTTPS for previews.
We run all of our traffic through a distributed edge network to deliver content and security improvements as close to to the user as possible. This is done for a variety of reasons and one of the big ones is that it offloads a bunch of the work our origin (aka the application) needs to do to purpose designed machines sitting in front that can accept an influx of traffic and move it around accordingly based on a series of rules without impacting the application.
The downside to this is that they are two individual components that work in isolation and it’s built this way by design. The rules that we have in place for the edge network must operate regardless of whether the application is healthy which means that we don’t expose or rely on any application level logic or data to drive the edge routing decisions. Item previews are one of these application level concerns and unlike the HTTP/HTTPS enforcement, cannot be determined without first connecting to the application and performing an item load.
Now, I bet you’re wondering “couldn’t Envato just add a bunch of rules into our edge configuration to handle this?”
Well…Regardless of how much money you throw at hardware for your routers, there is always (yes, always) a performance tipping point where the number of rule evaluations starts to cause your requests to slow down. The number at which this tipping point occurs between hardware + software combinations and the impact will also vary. Sometimes the performance overhead will be 1ms and in other combinations, it can be up to a 1s. What is worse is that in most cases I’ve seen, once this threshold gets violated the impact is exponential. We take performance metrics like this quite seriously and during our recent edge provider migration, we ended up halting the project until we figured out why one geographical region added 100ms while the others showed no change.
When we migrated to HTTPS, we ran some stats against the number of live previews that were HTTPS enabled and at the time, of the top 1000 or so, only 10-15 were. This was a relatively small number but with the information from above we made the call to not start adding in exceptions due to the maintenance overhead and complexity it would introduce. Speaking to one of the other engineers following the migration, they mentioned this number is on the rise (which is awesome!) but just backs up our initial thinking that as this HTTPS change was adopted our work to maintain it would have got far more difficult and we could have ended up in a situation where the cost would have continued to grow out of control.
In saying all this, we do have a soft limit that we impose on our configurations and unfortunately, this approach would push us over the threshold and potentially start slowing down the edge routing.
So, after all that are you saying that it won’t ever be fixed?
Definitely not! However, there will need to be quite a number of changes internally for this to be fully addressed before it will be viable for us to offer a fix.
There are some ideas floating around internally around how we might address this but none of them will be an overnight solution. Some good news on this deprecation from Chrome is that we enforce HTTPS across the marketplaces (even if you try HTTP, we upgrade the connection) so the actual purchasing and viewing side of things are covered by HTTPS as customers would expect.
New protections defend users against iframes redirecting users to unwanted sites.
This is another feature we are aware of and since this is how the live preview is intended to work (that is, previewed with an overlaying navigation bar), I’m afraid there probably won’t be many changes with this unless we end up replacing this piece of functionality with something that doesn’t rely on iframes but I’ll be sure to add it to the list of discussion points.
Do let me know if you’d like me to elaborate on any of these points as I’m happy to discuss any in more detail if it helps people understand the issue better!