XSS Part 3 – Session Riding, CSP policies, SameParty and SameSite

In my previous post XSS Part 2 Attack and Defence we looked at how an attacker can use XSS to steal a users session token from a cookie and then hijack it.

We then enabled the HTTPOnly option on our session cookie preventing malicious JavaScript from accessing the cookie value and sending it to the attacker.

Whilst HTTPOnly option will prevent this scenario unfortunately there is a another we need to address.

Obligatory Warning

Before we go any further obligatory disclaimer/warning/nag – do not perform any of the attacks we’ll discuss on sites you do not have permission to otherwise you could get into a lot of trouble or even jail.

A much better option to explore this topic is to use something like my deliberately vulnerable application https://github.com/alexmackey/hackthecat or HackTheBox.

Back to the content..

Ok where we?

Ah yes so the big issue we need to address occurs because if an attacker can execute code on a web page then it will operate as if it was legitimate code written by the site author with the same access to cookies, local and session storage.

Now browsers under most circumstances will automatically send cookies set by the site the user is browsing with any requests made via XHR & fetch requests (note that fetch requests require this to be explicitly enabled).

This can be a big issue when an XSS problem exists as because if a cookie value is used to identify a user (like in our example) and an attacker can get code to run on a page then they can call any API endpoint in the context of the logged in user!

Uh oh..

An attacker could then use this to:

  • Hit an API to change the user’s password to a known value (we’ll do this in a minute!)
  • Perform any valid action the user can – maybe this is transferring money in a banking application or purchasing products and sending them to the attacker or maybe exploiting some dumb Web3 NFT thing..
  • Perform additional XSS attacks but as the user themselves e.g. messaging other users XSS nastyness
  • ..and a thousand other horrendous things!

So how does this work?

Creating this attack is trivial and any web developer will have written similar (but probably better) code for completely legitimate purposes.

Below is an example of code that in the hackthecat application will change the password of the logged in user.

If we can get this to run in a page the user viewing it will have their password changed!

<script>
var formData = new FormData();
formData.append("username", "user");
formData.append("newPassword", "changed!"); 
formData.append("confirmNewPassword", "changed!"); 
var request = new XMLHttpRequest();
request.open("POST", "/user/change-password");
request.send(formData);
</script>

You can of course write this using fetch as well just remember you’ll need to use the credentials option set to “include” or “same-origin” otherwise fetch wont send credentials/cookies.

To see this in action yourself simply log into the hack the cat application (user and pass will do), go to a product and add a review with the above code.

When this runs you’ll then find this has changed the users password – here’s an exciting before and after mysql query screenshot – note how the password is “changed!” in the second query:

Local/Session Storage and Session Tokens

Some sites use local or session storage to save a users session token and then append it to requests rather than storing tokens in a cookie.

I think generally as the XSS code is executing in the context of the user this approach is unlikely to provide any additional protection. In fact it could make things worse.

I’m of two minds about storing session tokens in local storage. Whilst you are arguably in trouble if an XSS issue exists (due to the attack type we are currently discussing) you lose the benefit of how cookies work and expire and additional protection such as HttpOnly or SameSite options that are baked into modern browsers.

CSRF (Cross Site Request Forgery) Tokens

Some of you might be thinking oh this is where CRSF tokens come in – they’ll save me!

CSRF tokens are intended for preventing a different issue (you can read more about them here: https://portswigger.net/web-security/csrf/tokens).

CSRF tokens are likely implemented as a special value stored in a hidden form field that is sent with any requests and compared server side.

To circumvent this protection will require the attacker to read a value of a hidden form field which er really isn’t too tricky so in respect to this attack doesn’t really provide any protection (except against some very lazy attackers).

You should still however use CSRF tokens as they will of course offer protection against CSRF attacks – exactly what they were intended for.

What can we do to prevent this attack?

Apart from preventing XSS issues in the first place probably the most effective protection against this particular attack is to ensure that critical actions such as changing a password enforce the user to provide their original password first as hopefully the attacker and script will not have access to this.

I guess you could also implement a CAPTCHA but no-one wants to count how many Volvo’s are in a crappy picture displayed in a 16×16 grid – no they really don’t – do better.

We are however going to make the attackers life a lot harder by using Content Security Policy (CSP to its friends).

CSP headers (Content Security Policy)

CSP policies allow the client application fine grained control of what should and should not be running on a page and from where.

CSP policies are supported in every major browser and in a limited form in IE10+ (which hopefully you don’t have to support).

CSP policies can be set either in HTTP headers or meta tags and look something like this:

Content-Security-Policy: script-src https://simpleisbest.co.uk/

The above policy says scripts can only run from simpleisbest.co.uk and some other behaviours I’ll discuss shortly.

Below is the meta tag equivalent:

<meta http-equiv=”Content-Security-Policy” content=”script-src https://simpleisbest.co.uk‘ ‘self’;”>

What can you do with CSP policies?

Let’s say we have set the following CSP header on my site simpleisbest.co.uk:

Content-Security-Policy: script-src https://simpleisbest.co.uk/

Adding this header to HTTP requests will do the following:

  • Any inline scripts will be blocked (unless explicitly enabled with ‘unsafe-inline’ option) – this would prevent the XSS attack we have been discussing!
  • Inline event handlers e.g. onclick=”doSomething()” will be blocked preventing another attack vector
  • If the attacker tried to load a script from anywhere but simpleisbest.co.uk it’s going to be blocked
  • Several script execution methods such as eval(), Function, setTimeout, setInterval, setImmediate are blocked unless specifically enabled with unsafe-eval option
  • It prevents an attacker sending data to another server with html forms

Now the chances are when you first implement CSP policies especially on a site that has been around for a while some of these settings will break the site – you’ll find all sorts of dubious approaches in your code and perhaps third-party libraries doing some weird stuff!

Whilst you are first implementing CSP policies I suggest instead of using “Content-Security-Policy” I suggest you use “Content-Security-Policy-Report-Only” – you’ll see stuff that CSP would have stopped in the browser console instead of it being blocked making it easier to fix it up.

Enabling specific inline scripts

If for some reason you wanted to enable specific inline scripts (really?) but benefit from the protections CSP offers you can do this by adding a nonce to your inline script and then specifying the nonce to be expected like so:

Content-Security-Policy: script-src 'nonce-test'
<script nonce="test">
…
</script>

Ensure only specific scripts can be loaded

CSP policies allow us to ensure that only specific versions of scripts can be loaded by specifying an expected hash of the script like below (remember to include script tags, whitespace and that this is all case sensitive):

Content-Security-Policy: script-src 'sha256-yourSha256hashhere'

This is probably a good idea if you are referencing any scripts especially those on third party servers. This way you can be sure what your users will get is exactly as expected!

The downside of course is that its going to require some maintenance when scripts and assets are updated but it’s a small price to pay.

Which policies should I use?

CSP policies offer a huge number of settings to tweak.

Ideally, you want to only allow the minimum necessary for your site to function – this will reduce the surface attack area of your site and make the attackers life really hard if you can limit what options they have to utilise.

OWASP list the following CSP policy on their cheat sheet page (https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html)

Content-Security-Policy: default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self'; frame-ancestors 'self'; form-action 'self';

This will do the following:

  • All resources must be in same domain as document
  • No inline script, evals for script and style
  • No need for other sites to frame
  • No form submissions to external sites
  • Prevents loading of non ajax and CSS resources

This seems a pretty good base to start from and adapt to your purposes.

Adding a CSP Policy to HackTheCat

Ok let’s add a simple CSP policy to hackthecat site so we can see the impact.

We’ll do this directly in homeRoutes.js.

Add the following line before the res.render call in homeRoutes.js:

res.set("Content-Security-Policy-Report-Only", "default-src 'self'");

Note really you want this header to apply to every response so this isn’t the best way to do this as it will only apply to this endpoint. Also note that there are some third party express libraries to do this.

Once you’ve added this, restart the app, navigate to the page and you will then see something like the following in the browser console showing the inline script has been blocked:

Changing this to “Content-Security-Policy” mode will also display information about the referenced stylesheet hosted on fonts.googleapis.com being blocked as we haven’t said this is OK in our policy:

Deprecated approaches

You may come across a reference to various other XSS protection headers/options such as

  • X-XSS-Protection
  • X-Content-Security-Policy
  • X-Webkit-CSP
  • X-FrameOptions

These are all now deprecated and superseded by CSP Policies (for X-FrameOptions you can use frame-ancestors to provide protection against frame based evilness).

Using these legacy approaches can even cause security issues so don’t use them.

SameSite and SameParty

Before we wrap up this post I just wanted to tie up a loose end from the last post on SameSite and SameParty cookie options that you may have seen in the browser dev tools:

SameParty is a proposal designed to deal with the issue that modern sites are often served over multiple domains owned by the same entity. The intention is to allow developers more control over the privacy boundaries of where cookies are shared.

As this is still a proposal I’m not going to worry too much about it at this stage but its an interesting idea. You can read more about this proposal here: https://chromestatus.com/feature/5280634094223360.

SameSite however is ready to use now and supported in all major browsers apart from our old friend IE11.

Same-site is designed to protect against CSRF and potential information leakage by allowing developers to control that it should only be sent from requests initiated by the domain it was created in.

This is different to the default cookie behaviour where cookies are automatically sent to the same domains that they were set in.

Same site has 4 main options:

  • Strict
  • Lax
  • None
  • Unspecified (behaves the same as lax)

What do these SameSite options do?

Let’s assume a scenario where:

The user has a cookie set by my domain simpleisbest.co.uk

The user is on an external blog site hosted at wordpress.com

Strict
If the cookie had SameSite set to strict then the following will occur:

  • If the blog site references an image on simpleisbest.co.uk then no cookies would be sent to simpleisbest.co.uk from this request
  • If the user were to follow a link from wordpress to simpleisbest.co.uk then on the first request they make no cookies will not be sent offering protection against CSRF attacks that rely on the user being logged in and clicking a malicious link
  • Once the user is on the site e.g. they click a link on simpleisbest.co.uk then cookies will be sent as they are now in a first-party context (e.g. on the site that set the cookie).

Lax
When SameSite is set to lax then:

  • If the blog site was referencing an image and requested an image from simpleIsBest.co.uk then no cookies would be sent as per strict mode above
  • Unlike strict mode however if the user follows a link to simpleIsBest.co.uk then cookies will be sent.

None

When SameSite is set to None:

  • If the blog site was referencing an image on simpleIsBest.co.uk then cookies would be sent with the request
  • If the user follows a link from another site to the site that set the cookie (simpleIsBest.co.uk) then cookies will be sent
  • Note you must set the secure attribute on cookies when using None

Unspecified

Unspecified now behaves the same as Lax (recent change).

Ok let’s wrap things up – in this post we looked at how XSS can without further protections in place allow us to execute actions in the context of the user such as change their password or call arbitrary endpoints via XHR or fetch.

We then looked at how CSP policies provide fine grained control of what functionality can run in a page and can prevent or at least make an attackers life a lot harder then finally we looked at SameSite and SameParty cookie options.

In my next post I’ll show how an XSS issue can be exploited to run arbitrary code on a webserver which is pretty much as bad as things can get!

XSS (Cross Site Scripting) Part 1 – What is XSS?

I’ve been interviewing web developers recently and was surprised that the majority did not know what XSS (Cross Site Scripting) is.

Perhaps part of this is that many web developers will begin their development career using a framework such as React or Angular that abstracts what’s actually going on.

Many frameworks will now also provide sensible defaults that can help prevent many XSS issues and you have to go out of your way to get round these for example React warns you that you are probably about to do something potentially silly with its wonderfully named dangerouslySetInnerHTML method.

However its still very possible despite some of these protections and defaults to have XSS issues so if you are developing for the web it’s important you understand what XSS is and how to prevent it.

XSS is a surprisingly big topic (and I certainly learnt stuff putting this series of blog posts together) and we’ll be going deep into this topic so I’m going to split this up into what’s hopefully a series of more digestible articles rather than a 30,000 word mega post.

In this series of posts, I will:

  • Introduce XSS and talk about its different types
  • Talk about what an attacker could do with XSS
  • Show an example using my demo app of how XSS could lead to compromised accounts and even RCE (Remote Code Execution) when combined with other issues
  • Look at ways to mitigate or prevent XSS
  • Review some of the thousands of ways XSS can occur and how attackers circumvent various protective measures and what to do about it

Important!

As with any offensive security topics its important you do not use these methods and techniques on sites you do not own or have permission to test on.

Trying some of the techniques we’ll discuss on sites you don’t have permission to is almost certainly illegal and you could end up in a lot of trouble or even jail.

There’s plenty of great labs to explore security topics such as hackthebox, tryhackme or bug bounty programs where you can learn and help make stuff safer which makes the world a better place.

These are all much better options than a criminal record/jail time..

Hack The Cat (vulnerable Node/Express application for learning/teaching appsec)

I wanted an application to play, learn and teach some of these issues so I’ve been developing a deliberately vulnerable Node/Express application called Hack The Cat that contains many different security issues (below):

Whilst early in its development I’ve added various common security issues including:

  • Various XSS vulnerabilities
  • SQL Injection
  • Serialization issue
  • File upload with naïve filter

My plan is to expand upon this and also add the following:

  • SSTI (Server Side Template Injection)
  • More advanced XSS filters
  • LFI & RFI (Local/remote File Inclusion)
  • OS command injection
  • JWT issues

Anyway i’ll release this shortly with a MIT license so its free for all but let’s talk about XSS.

What exactly is XSS?

XSS or Cross Site Scripting is one of the most common web security issues and occurs when a website accepts malicious client-side code or HTML and then executes it in the context of the user who is visiting the site.

A simple example of XSS would be a shopping site that allows users to post reviews of products and then renders the reviews submitted.

If an attacker can submit a comment containing a script block like say below..

<script>alert('hello you have XSS issue you'll need to fix up')</script>

..and the browser renders it without encoding this then you’ll be greeted with an annoying smug alert box.

In fact if right click/view page source on this blog post and search for “hello” in the source code you’ll see something like below:

Here, WordPress has thankfully properly encoded this code block – if they didn’t you’d all be seeing an alert box as it would run as if the original site developer had added it.

If you want to see just how common XSS issues are and how they can be used go to https://www.exploit-db.com/ (a site that contains a massive index of security issues and code for utilizing them) and search for “xss” – wow quite a few issues..

XSS was apparently “discovered” by the Microsoft Security Response Centre and the IE Security team who heard about attacks where script and image tags were injected into web pages. In 2000 they published a report in conjunction with CERT where the term Cross Site Scripting was first used.

Whilst popping up an alert box and taking your users back to early 2000’s web/common current debugging techniques is certainly annoying an attacker could do much worse and this can be used to devastating affect.

For this we need to get into cookies and sessions.

Cookies and Sessions

XSS can become especially destructive due to how web site sessions & cookies work.

Cookies are pretty important and one way of holding state about a visitor. Cookies are one of the main mechanisms websites use to identify individual user on a website and understand if a user is logged in.

When I log into many sites the site will issue me a cookie to identify me and that I should be able to access the site.

Now the thing about cookies is that they are sent with any request made from a site or “origin” (there are a few exceptions such as using fetch which doesnt send cookies by default and certain configurations we’ll talk about later).

Now this can be a big issue as if an attacker can get code to run on a site as we know that cookies are being used to identify users then the site may think the request is from a legitimate user!

Same-origin policy

Before we move on I just wanted to mention same-origin policy as this relates to cookies and will also prevent or make harder some types of attack.

This can get quite complex so here’s an overly simplified version.

Same-origin policy places restrictions on what a document or script can do when a page is loaded from one origin and interacting with another.

A site is considered as having the same origin if the following match:

  • Its protocol (http/https)
  • Port (if specified – note weirdly IE ignores the port bit because er IE)
  • host (the address bit – it’s more complex than this but anyway)

The following for example would be considered to have the same origin:

https://simpleisbest.co.uk

https://simpleisbest.co.uk/some-page

Now this is important as if an attacker is running a script on another server (origin) then they wont be able to do certain things (at least directly) like steal cookies. This is a good thing.

Ok enough theory lets talk about different types of XSS.

Different Types of XSS

XSS comes in several different and overlapping ugly flavours you should be aware of:

  • Stored XSS
  • Blind XSS
  • Reflected XSS
  • DOM Based XSS

Persistent/Stored XSS

In Stored XSS the attacker manages to save their horrible XSS payload somewhere (most likely a database as they are good for this kind of thing unlike er blockchain which really isnt very good at anything).

The bad news with Persistent/Stored XSS is that once malicious code is stored it could potentially be executed for thousands of users who don’t have to do anything but visit your site where the code is rendered which can give it a massive reach.

I guess you’d also have to clean up the stored malicious content at some point in your database which could be really annoying if an attacker automated the creation of thousands of comments.

Blind XSS

Blind XSS is a form of Persistent/Stored XSS but has the difference that the attacker is not sure when the code will actually execute and if at all.

Er what?

Imagine an application that allows the sending of a contact form message to admin users.

When an admin user views this message then the malicious code will then execute in the context of the admin user. This malicious code could then be used potentially to perform administrative functions, steal the admin’s session cookie etc as its executing in the context of the admin user.

In Blind XSS the attacker may not have access to the code base/application so they cant be sure their code will ever actually execute.

An attacker might send code that will “ping” a remote server or endpoint by perhaps requested an image and then monitor to see if a blind xss attack was successful. They could then perhaps send more information about the page its executing on.

Reflected XSS

Reflected XSS occurs when the XSS payload is not actually stored but is “reflected” back to the user.

A site may have a search function that allows users to search for products and then sends the search values unencoded in the query string e.g. simpleisbest.co.uk?search=<script>something bad</script>

Attackers could potentially send users links like the above that are pointing at a legitimate site that then executes their malicious code.

An attacker would likely take care to obscure their payload more carefully than the above example and this could be obscured with various methods e.g. JavaScript’s String.fromCharCode method and a hellish number of different encoding schemes that most browsers support.

It’s important to note that reflected XSS requires a user to perform an action (e.g. click the link) and may be avoided by more knowledgeable users or automated systems that scan emails for malicious content.

Reflected XSS attacks are likely to have limited reach compared to persistent/stored XSS.

DOM (Document Object Model) based XSS

In DOM based XSS the attacker finds a way to inject a payload into the pages DOM without modifying the HTML directly.

A site may after login put the users name in a query string to display a welcome message that is then output on a page e.g. simpleisbest.co.uk?username=Alex

If the receiving code doesn’t encode the output properly then an attacker could supply a malicious bit of code in the username parameter that would then be output and executed on a page.

DOM based XSS can be harder to find/scan for as the attacks never reach the server itself.

So what’s the big deal about XSS?

Whilst using XSS to pop up an alert box or maliciously redirecting users to Michael Buble’s site could be very annoying XSS can be devastating when chained with other attacks.

Depending on other protections & configuration in place we’ll talk about in the future XSS can be used to do pretty much anything a user on that page could do as code will execute in the context of that users browser.

This means of course that the code can:

  • Transverse and manipulate the pages DOM
  • Read users cookies, local and session storage (depending on other protections in place)
  • Send requests to backend APIs in the context of the current user even if not used on the current page
  • Redirect the user to other sites/applications
  • Modern APIs have access to the camera, geolocation, microphone and certain files (these will require user to grant permission if they haven’t already)

And any other endless possibilities – basically anything you could do with client side code in the context of the current user

This means an attacker could:

  • Harvest and steal session cookies (depending on other protections in place) allowing them to act as if they are the user logged in until the cookie/token expires or is revoked
  • Perform actions in the context of the current user as the browser will send cookies with any requests made e.g. change their password to something known
  • Transverse & manipulate the DOM to pull out sensitive information
  • Manipulate the DOM and trick users into performing certain actions or reading wrong information
  • Redirect the user to other sites e.g. a site hosting malware or Michael Buble’s music
  • Defacing a site and replacing it with other content (hopefully not Mr Buble’s music)

Ok so hopefully I’ve convinced you XSS can be a pretty big deal.

In the next post i’ll show an example with my demo application of how it could be used to gain control of an admin account and even an entire server and then we’ll look at how we can fix this up.

Further reading

https://medium.com/@ryoberfelder/describing-xss-the-story-hidden-in-time-80c3600ffe81

https://portswigger.net/web-security/cross-site-scripting

https://owasp.org/www-community/attacks/xss/

What is Project Spartan and is IE dead?

It is naughty & generally a bad idea to isten to rumours but around September 2014 & again early January 2015 you may have heard that Microsoft was developing a new browser with the code name Project Spartan.

However it wasnt until 21st of January 2015 at a Windows 10 preview event that Microsoft confirmed the existence of this browser and gave us our first peek.

Oooo but most importantly what does it look like?

Well we can’t get our hands on it yet so we are reliant on demos and Microsoft blog articles. Here is a picture I have taken from the IE blog of Project Spartan’s UI to give you some idea:

spartan

A nice clean simple UI that bears very little resembalnce to Internet Explorer.

Tell me about the new features in Project Spartan..

Well it is still very much in development but here is a summary of some of the new features we know about so far compiled from various blogs, the Window 10 video and tweets from IEDevChat:

  • A nice new clean UI that bears little resemblance to IE’s
  • Ability to annotate & comment on web pages (and PDF’s!) to highlight issues/impress your co workers with your cat drawing abilities
  • Spartan can save content for later viewing offline. This feature is also integrated into Windows reading list application & I assume can sync between devices
  • Reading view – a distraction free version of a page optimized for the reading of content. This feature was actually first introduced in the Metro version of Internet Explorer however you probably never noticed unless you had a Surface device as Windows Metro mode was er pretty horrible
  • Integration with Microsoft’s digital assistant Cortana. In the launch event a demo was shown where the user started searching for weather in the address bar & the browser showed a weather forecast specific for that users location.
    A more complex example was also shown where Cortana was aware the user was tracking a particular flight & automatically pulled flight status details when the user searched for the flight/airline
  • Updated F12 developer tools – you can see some of these great new features in the latest version of IE11
  • Fixes for over 3000 interoperability issues
  • Possibility of an extensibility model (or perhaps more accurately one you’d actually want to use!). @IEDevChat tweeted “We’re working on a plan for extensions in Project Spartan. Stayed tuned!”  and “Still building our plan for extensions, but we’ll share more once we have details”. Cant wait to see what they have planned & I hope it will be similar to Chromes model
  • Microsoft say they are working on implementing over 40 new web standards including support for accessing the dom using XPath syntax, Web Audio, Media Capture API, WebRTC 1.1, Touch Events, Content Security Policy, HTTP/2
  • Apparently IE preview has the best support for ES6 features at the time of writing
  • A new User Agent String containing various other browser identifiers aimed at making sites work that would previously have excluded IE by user agent sniffing (never a good practice)

annotation

Above Project Spartan’s annotation features shown at Windows 10 event

Spartan sounds interesting how can I play with it now?

Not quite. You can’t quite yet play with the new UI/annotation features as they are still cooking but you can see the new rendering engine in action by downloading a preview of Windows 10 at http://blogs.windows.com/bloggingwindows/2015/01/23/january-build-now-available-to-the-windows-insider-program/ & enabling Edge mode by opening up the browser and going to about:flags.

So is this the end for IE?

Jacob Rossi says “Spartan is the browser we expect people will be using on Windows 10”.

So for the majority of consumers in the future er kinda yes..

However this is not the full story.

Before I answer this we need to understand that browsers are actually made up of many individual components and subsystems. In fact it’s probably better if you head over to the IE blog here and you can learn all about what makes up Internet Explorer from the people that actually create this stuff – go on i’ll wait.

Internet Explorer in its rendering related system(s) contains a huge amount of code dedicated to providing support for legacy versions of IE all the way right back to IE 5.5.

As you can imagine maintaining this became a bit painful (and does anyone really need support for weird IE5.5 rendering issues – no you don’t) & can slow progress. With Spartan Microsoft decided to draw a line in the sand and based Spartan’s rendering engine on IE11’s standards support and went to work throwing out the older legacy rendering stuff (and a few other items such as vbscript that no one not even its mother will miss).

So in short Spartan is built upon the rendering & JavaScript engine of IE11 (and I guess some other components) but without the old legacy stuff.

The result is a great standards compliant platform with an awesome JavaScript engine to build upon going forwards. Microsoft are referring to this new rendering engine as EdgeHtml.dll.

But what about backwards compatibility? glad you asked let me tell you about Spartan’s dual engine mode..

I work for a bank/government agency and am worried about backwards compatibility!

To support legacy applications Spartan operates in dual engine mode and transparently switches (it is unclear what triggers this) between using the new engine & the old Trident/MSHTML engine for legacy sites.

Internet Explorer will also be made available on Windows 10 to support those guys that have built applications on top of IE’s extensibility models toolbars/ActiveX etc (you poor brave fools!).

It looks like it is still to be decided if IE will be hidden away in order to encourage Win 10 users to move to Spartan. For example in a reply to a tweet regarding if IE will be part of Windows 10 @IEDevChat replies that “We’re evaluating different approaches, but our intent is for ppl to use Spartan unless they have specific compat needs”.

Can you force EdgeHTML rendering on intranet sites?

Yes. “You can get EdgeHTML on intranet using x-ua-compatible if intranet sites are set to use compat view.”

Why can’t Spartan/IE just use WebKit/Blink as its rendering engine – my life would be much easier?

Well maybe but having no completion/a mono culture is a very bad thing for a number of reasons.

Christian Heilmann (probably best known for his work at Mozilla but now working for Microsoft) answered a comment on Jacobs article similar to this with:

“The fact of the matter is that in order to have a standards based web, we have to have different browser engines to test standard proposals against. Having a WebKit only web would be as disastrous as having an IE6 only web or a Gecko-only web. Any engine that has no competition will deteriorate over time – no matter if it is open or closed.”

And I would certainly agree – competition and different is good and drives the web forward & stops one organisation having control over the webs direction.

Will Spartan auto update?

Yes Spartan is “Evergreen”.

Which operating systems can I use Spartan on?

Initially Windows 10 & Windows Phone 10. Remember that Win 7 updwards users will be able to upgrade to Windows 10 for free so there is really no excuse unless perhaps you are in Corporate world. Microsoft said regarding potential cross platform support in the future: “No current plans, we’re focused on making it great for Win10.”  and “Spartan is currently targeted at Win10. We’re focused on getting ppl upgraded (free) but will watch Win7 demand”

Will Spartan use vendor prefixes?

It will likely still contain some but these will be discouraged. “EdgeHTML engine will have a lot of ms prefixes removed; we want to use prefixes very sparingly if ever”.

Were there perf gains from removing the old rendering stuff?

“Yes. The disk size of the engine itself is decreasing and general web page performance has improved by various metrics, including JS perf. Preview builds are notoriously not our best foot forward with perf though, but you should see good things already and we’re not done yet.” Jacob Rossi comment http://www.smashingmagazine.com/2015/01/26/inside-microsofts-new-rendering-engine-project-spartan/

Which IE engine will web driver use?

The new Edge engine. John Jansen in a comment at http://www.smashingmagazine.com/2015/01/26/inside-microsofts-new-rendering-engine-project-spartan/ said:

“We are definitely committed to the Edge engine with WebDriver. We are still working out details about how it must work, but it should never randomly switch between them for no apparent reason. I expect that you will be able to test your internet sites or intranet sites in ways the very closely mimic the actions a real user would see and do”.

Upon release will the browser still be called Project Spartan?

If history is anything to go by Microsoft Marketing or whoever names MS products has a consistent ability to remove cool names so probably not.

I am a site developer what does this mean for me?

You should continue to develop your sites and applications using current standards and everything should be marvellous.

Will Spartan be integrated as closely integrated with Windows as previous versions?

Personally I hope not & in an ideal world I would like to see it possible to run Spartan entirely off a USB stick. I have my suspicions that Spartan may have some deep links given it integrates with Cortana, Sharing of comments, Reading list etc but guess we will have to wait and see how this will work.

Additionally in previous versions of IE many products took dependancies on IE components e.g. Outlook utilized it for rendering HTML email. Having these dependancies may have slowed development as the IE team would have had to be careful not to break these applications reliant on these components.

It is also worth noting that as Spartan updates automatically updates should not be quite as big a deal as they were previously so maybe if there is a close Windows integration it wouldnt be such a problem.

What new HTML/CSS/JavaScript features will Spartan have?

Head over to staus.modern.ie for the most up to date view.

When will it be available to use?

No idea.

Further reading/watching

You can watch the full preview event at http://news.microsoft.com/windows10story/. Note if you just want the Spartan related stuff fast forward to an hour in 🙂

https://twitter.com/iedevchat
http://blogs.msdn.com/b/ie/archive/2015/01/22/project-spartan-and-the-windows-10-january-preview-build.aspx
http://www.smashingmagazine.com/2015/01/26/inside-microsofts-new-rendering-engine-project-spartan/
http://www.aaron-powell.com/posts/2015-01-25-project-spartan-and-internet-explorer.html

jQuery mobile experiences

Mobile optimized website projects seem to becoming increasingly common so I thought I would summarize some of the advantages & disadvantages we have experienced with using the JQM framework (jQuery mobile http://jquerymobile.com/).

But why would you use such a framework in the first place?

Well you certainly don’t have to (and in many cases probably shouldn’t) but JQM:

  • Tries to take care of various niggly display issues across multiple types of devices
  • Provides an abstraction over various events e.g. rotating a device, swipes etc
  • Takes care of history management
  • Gives you various controls similar to what exists in an iphone (because in my experience most clients seem to think a mobile site should look like an iphone app – websites are different from apps grrr – anyway moving on..)

Good things:

  • Our app on the whole displays pretty well across multiple device types with little effort e.g. iphone, ipad, various android devices & win phone 7
  • Was very quick to get up and running with JQM
  • Our brief was to copy existing iphone app and we were able to do so pretty easily
  • JQM has good documentation and examples

However we also encountered a number of issues with the framework.

Bad things:

  • JQM mobile leaves other pages in the dom (even multiple copies of the same page) which means you need to be careful with giving all selectors a context. There doesn’t seem to be a way to disable this apart from turning the ajax loading off which removes one of JQM’s biggest benefits of hijax loading
  • JQM interferes with the event model and a couple of “standard” jquery type methods such as event.preventDefault don’t work properly
  • At times JQM feels sluggish (apparently this is due to delays in place to handle taps for various device types)
  • JQM interferes with markup and adds its own styling & elements. Most of the time this is fine but we had a couple of pages that crashed ipod touch devices and iphones. This seemed to be related to number of dom elements on page
  • JQM seems to queue touch events so if you rapidly click the clicks seem to be queued up when you return to a particular page
  • Its v1 so there are a number of bugs in it

I am not sure if I would use JQM again because of some of these issues – towards the end of the project I felt we were fighting the framework. Much of the functionality e.g. transitions wouldn’t be too tricky to develop yourself. It is however excellent for small projects particularly if most of your pages are static content.

Image Optimizer extension for VS2010

I came across a nice free extension for Visual Studio 2010 for quickly optimizing images within Visual Studio IDE. Image optimizer uses external services such as smushit and PunyPNG to reduce the file size of your images with no visible loss of quality. As this results in less downloads for your users it’s a bit of a no brainer to implement.

To install the extension open Visual Studio and go to Tools, Extension Manager, Online Gallery and search for Image Optimizer and then click Install.

Once the extension is installed you can right click on a folder and select Optimize Images to have all the images in the folder optimize (check the files are not read only/checked out otherwise you will get an exception when the add on attempts optimization.

Once Image Optimizer has finished optimizing the images it will give you a summary of how much it has reduced file size by. Below shows the output from a recent project:

14 skipped. 142 optimized. Total savings 57.27%