In this post we will discuss what Key Management System is and what are the main features of it. Furthermore, we will show how you can integrate KMS with AWS lambda and migrate your signing and verification workload to the KMS service. At last, we will discuss a limitation on creating CSRs in the KMS service and a solution for it using Bouncycastle and Java. :rocket:

What is KMS service

The key management service (KMS) is a service for the creation and management of the cryptographic keys. You can create both symmetric keys as well as asymmetric key pairs to perform encryption, decryption, signing, and verification process in your applications. Signing and verify in AWS kms feature is relatively new compared to encryption and decryption.

Key features

KMS is a fully managed service and can integrate with plenty of AWS services easily. KMS uses a hardware security module to keep the cryptographic keys secure. AWS KMS is designed so that no one, including AWS employees, can retrieve your plaintext keys from the service.

Characteristic of the key

For the propose of this post, I am using an EC key pair to sign my content with the private key of that key pair. More specifically, the “key-spec” I am using is an asymmetric NIST-recommended elliptic curve key pairs, EC_NIST_P256 for signing and verification. On this page, you can see which configuration is most suitable for your case.

What is CSR and why we need to create one CSR

Certificate Signing Request (CSR) is a message from an applicant to a certificate authority(CA). You normally apply for a digital certificate to a CA by sending them a CSR. The most common format for CSRs is the PKCS10 specification, usually represented as a Base64 encoded. A CSR usually consists of three parts:

1. A subject including identity information like country, state, city, organization name, and so on.
2. The public key for which the certificate should be issued
3. A digital signature on point one and two. This integrity protection ensures the CA that nothing has changed in the communication channel.

Kms signer application

Let’s create an application to demonstrate how you can migrate your signing workload on KMS. I am using Serverless framework for creating my AWS resources. If you are not familar with this framework, take a look on this page

• Create a Aws Lambda ​ sls create -t "aws-java-maven" -n kms-signer

First step: Create lambda and API gateway

• Add post method as a trigger to the lambda function in serverless.yml

  events:
    - http:
        path: sign
        method: post

• Deploy Congratulation! You created a lambda function and an API gateway for it. It is time to deploy it on AWS. Don’t forget to build your project before deploy! ​ sls deploy

• If the deploy goes well, you will get a link to your API in the logs. You can test the API using a REST client e.g. curl like following:

curl --location --request POST 'https://<MYURL>/dev/sign' \
--header 'Content-Type: application/json' \
--data-raw '{
	"message": "sign-this!"
}'

Ofcourse you get a default result which has created by Serverless framwork. In the next step we will put the application into context and send back an actual result from the API. You can read the logs on CloadWatch console, or easier using this command:

​ sls logs -f <FUNCTION-NAME>

BONUS:

Useful log messages that you can put in your lambda to observe system environment variables, context data, and event data are as following.

// log execution details
LOG.debug("ENVIRONMENT VARIABLES: {}", gson.toJson(System.getenv()));
LOG.debug("CONTEXT: {}", gson.toJson(context));
// process event
LOG.debug("EVENT: {}", gson.toJson(event));
LOG.debug("EVENT TYPE: {}", event.getClass().toString());

Second step: Create a EC key pair

In the time of writing this post, CloudFormation does not currently support creating asymmetric CMKs. So we need to do it in the Console or Aws Command line tool. You can find a comprehensive description on how to create a CMK here

Third step: Add IAM Role

The Lambda needs to have correct IAM ROLE to be able to access the CMK you have created in the previous step. To give access, you need something like following the IAM role statement in your serverless.yml.

iamRoleStatements:
  - Effect: "Allow"
    Action:
      - kms:GetPublicKey
      - kms:ListKeys
      - kms:ListResourceTags
      - kms:Sign
    Resource: "arn:aws:kms:<REGION>:<ACCOUNT>:key/<KEY-ID>"

Fourth step: Sign a string using kms

First of all you need to include aws-java-sdk-kms dependency to your project dependencies. Then, You need to define another function handler and corresponding API gateway for it. Finally, you create a method that gets a serilized object as an argument and send a sign request to the KMS. For example you can look into following example:

public byte[] sign(final byte[] message) {
  final SignResult signResult = AWSKMSClientBuilder
      .standard()
      .build()
      .sign(getSignRequest(message));
  return signResult.getSignature().array();
}

private static SignRequest getSignRequest(final byte[] signingInput) {
  final byte[] hashedInput = DigestUtils.sha256(signingInput);
  final ByteBuffer message = ByteBuffer.wrap(hashedInput);
  return new SignRequest()
      .withMessage(message)
      .withMessageType("DIGEST")
      .withKeyId("<KEY-ID>")
      .withSigningAlgorithm(SigningAlgorithmSpec.ECDSA_SHA_256);
}

Fifth step: Create a CSR programmatically

So far, so good! You have an application that can sign content for you. You can send your signature and your public key to a third party entity, and that entity is able to verify your signature. One problem is remaining, though! What if an attacker forges your signature and public key. You need to ensure the other entities that your public key is authentic.

First, you apply for a certificate by sending a CA a CSR. The digital certificate you eventually get from the CA is confirming the authenticity of your public key. Traditionally, you create a CSR with OpenSSL tool with these steps:

1. First generate a pair of keys: openssl ecparam -out private.key -name prime256v1 -genkey
2. Then using these pair of key to generating a CSR. Note that you need private key for having a “Applicant signature” on your CSR openssl req -new -key private.key -out my-csr.csr -sha256

The issue in KMS is the CSR creation feature is not an available feature. Additionally, no one can have access to the private key generated on KMS. So this is a deadend way?

No, using the Bouncycastle, we are able to create a CSR. By using PKCS10CertificationRequestBuilder class from PKCS package, we create a “pre-build” CSR object which would need a ContentSigner. All we need to do is implement ContentSigner interface and glue the “sign” method we created before to this class.

public class AwsKMSContentSigner implements ContentSigner {

  private final ByteArrayOutputStream outputStream;
  private final AlgorithmIdentifier sigAlgId;
  private final AwsKmsSigner signer;

  public AwsKMSContentSigner() {
    this.sigAlgId = new DefaultSignatureAlgorithmIdentifierFinder().find("SHA256WITHECDSA");
    this.outputStream = new ByteArrayOutputStream();
    this.signer = AwsKmsSigner.getInstance();
  }

  @Override
  public AlgorithmIdentifier getAlgorithmIdentifier() {
    return this.sigAlgId;
  }

  @Override
  public OutputStream getOutputStream() {
    return this.outputStream;
  }

  @Override
  public byte[] getSignature() {
    byte[] signedAttributeSet = outputStream.toByteArray();
    return signer.sign(signedAttributeSet);
  }

}

Additionally, pass it to the PKCS builder. The builder uses the signer to generate the “application signature” on the CSR.

public String createCsr() {
  PKCS10CertificationRequestBuilder p10Builder = new JcaPKCS10CertificationRequestBuilder(
    new X500Principal("CN=Signer, O=MyOrg, OU=MyOrgUnit, C=Gothenburg, L=Sweden"),
    getPublicKey());
  ContentSigner contentSigner = new AwsKMSContentSigner();
  PKCS10CertificationRequest csr = p10Builder.build(contentSigner);

  PemObject pemObject = new PemObject("CERTIFICATE REQUEST", csr.getEncoded());
  StringWriter csrString = new StringWriter();
  JcaPEMWriter pemWriter = new JcaPEMWriter(csrString);
  pemWriter.writeObject(pemObject);
  pemWriter.close();
  csrString.close();
  return csrString.toString();
}

Done! The output is something similar to this:

-----BEGIN CERTIFICATE REQUEST-----
MIIBKDCBzwIBADBtMQ8wDQYDVQQHEwZTd2VkZW4xEzARBgNVBAYTCkdvdGhlbmJ1
cmcxGzAZBgNVBAsTEk15T3JnYW5pemF0aW9uVW5pdDEXMBUGA1UEChMOTXlPcmdh
bml6YXRpb24xDzANBgNVBAMTBlNpZ25lcjBZMBMGByqGSM49AgEGCCqGSM49AwEH
A0IABEGM2IMVUC3edUwly1y+G+ufLXbCVj6Ee9Dqz/XFEV7goD2twHBok+kGQxqN
nYkgBDIw54F9JtWWEhSch8QIluCgADAKBggqhkjOPQQDAgNIADBFAiEA3WFMR7mg
nF4VqCh1sFoLoxoAdvZvRpAa/F4wyvJQjU0CIEVxatmlGXzmoBY/MKHPiXG2UKVu
0yOb6ZsZeFQoHHN1
-----END CERTIFICATE REQUEST-----

Verify the signature in CSR

If you want to verify the digital signature inside a Certificate Signing Request, you can use the OpenSSL “req -verify” command as shown below:

openssl req -in myCsr.csr -noout -verify

The output “verify OK” indicates that the decrypted digital signature matches the digest of the CSR data.

Useful links

• SSL shopper https://www.sslshopper.com/
• Cert logik https://certlogik.com/decoder/
• https://aws.amazon.com/blogs/security/digital-signing-asymmetric-keys-aws-kms/

Background

A couple of years ago I was working on a large codebase with a lot of dependencies between features where we often missed to implement new functionality for all use cases in the product, as it was quite impossible to know all functionality that we supported. When I first learned about the visitor pattern I felt like it solved all my problems, I could now extend my data types and all code that used the types would need to implement handling of the newly added cases. The visitor pattern require you to explicitly handle all potential data it can contain, which is nice, but the downside is that it produces a lot of boilerplate code and isn’t really intuitive to understand, it felt like I had to read up on the pattern over and over again. Enter union types.

Union types

Union types, or discriminating unions, are basically a type which can contain one value of one of its specified types, similar to how in a data format specification you might want to say “a value is either a boolean, a string, or a number”.

In TypeScript using a union type might look like this

const value: boolean | string | number = "hello";

or in F# like this

type ValueType =
    | Boolean of bool
    | Text of string
    | Number of int
    
let value = Text "hello";

or in C# I have created my own open source project for union types

Union<bool, string, int> value = "hello";

What is great about the union type is that you cannot access specific functionality of the value type unless you first can guarantee the functionality is available. Lets say we now want to get the number of characters of our value, I’ll treat true/false as text in this example:

In TypeScript this might look like this

function getNumberOfCharacters(value: boolean | string | number): number {
    if (typeof value === "boolean")
    {
        return value ? 4 : 5;
    }
	else if (typeof value === "number")
    {
        return value.toString().length;
    }
	else 
    {
        // Here we know it's a string, which has a length property
        return value.length;
    }
}

const characters = getNumberOfCharacters(value);

or in F# like this

let getNumberOfCharacters value =
    match value with
    | Boolean boolean -> match boolean with
        | true -> 4
        | false -> 5
    | Text text -> text.Length
    | Number number -> number.ToString().Length
    
let characters = getNumberOfCharacters value;

or in C# for my union type

var characters = value.Map(
        boolean => boolean ? 4 : 5,
        text => text.Length,
        number => number.ToString().Length
    );

Another nice thing here is that if we should include an additional type in the value union type in the future the code wouldn’t compile. In the case of TypeScript I would no longer know it’s a string type in my last “else”-case, in F# I would no longer be matching on all possible values, and in my C# library I would be missing a Func as parameter.

How I use union types

Lately I’ve been working mostly with REST API:s, where my use case has been that I should execute some kind Create/Read/Update/Delete operation and report back either a successful result or a failure result with data detailing why the operation failed. Commonly the failure cases are validation errors, missing data/resources, conflicting modifications, or insufficient permissions. In backend services I’ve seen many different kinds of result classes, often with implicit relation between data properties which you as a user of the service need to understand to access the result properties safely. In my library I have implemented a result type which is basically just a union type with extra methods to deal with the success case. This can be useful if you for example use the backend services both for a public REST API, where error handling is very important, and for an internal API or tool for developers where you only care if operation executed as expected. It also makes it more semantically clear what is the expected result than just using a union type directly.

Summary

I believe union types is a good way of handling multiple data types while maintaining strongly typed code, and as a way to minimize need of dependent properties of data objects. Even if your language of choice doesn’t support it natively you can hopefully implement it yourself.

If you’re a C# developer feel free to try out my generic data structures project for union types, any and all feedback is appreciated!

Svelte uses new controversial ways of going about things that have caught my interest. In this article I will present an overview of Svelte.

Problems to solve

Bundle size

A common problem with web applications today is that the bundle size is way too large to provide a fast user experience. Not only does the code need to be delivered over a network, it also needs to be parsed before anything can be painted to the screen. A common problem with almost all frameworks today. Solutions like code splitting and server side rendering exists but I rarely see that they are used. Code splitting can also not be done on the framework bundle, typically the largest portion of the bundle anyway.

Performance

Declarative code style is very popular. In the case of React, given a set of input props it declares what markup should be produced. Not how, but what markup. Under the hood React uses a “virtual dom” mechanism that compares every single piece of the old markup against a proposed new markup. If any difference is found, React will access the “browser dom” and perform the actual update.

Things to learn

Developers like things that are easy to learn but have a flexible nature. A trend amongst frameworks since the jQuery days is that there are typically less framework specific details to learn. jQuery had a ton of API to learn, Angular 1.x had its share of boilerplate, React has reduced that even more. But this article is about to describe Svelte, which in my humble opinion has been the easiest framework to learn to date since there actually aren’t that much to it.

Solution attempts

The creator of Svelte, Rich Harris, recognized that frameworks aren’t made for organizing code, they only organize our minds. Meaning that the translation from declarative code (the what) to imperative code (the how) might as well be done at build time rather than at run time. This moves the necessity of a framework being present from the client browser to the build step. If we don’t need to ship a framework to the client, the bundle size can be significally smaller.

Svelte also doesn’t use a “virtual dom” to keep track of updates, it uses shallow equality comparison along with a “reactive operator” to know what to update. It does so by producing the actual dom api calls needed to make the update. That also gets rid of a complete category of performance problems. Therefore Svelte is also very fast.

Svelte is currently at version 3, which fundamentally works the same way as version 2, but it focuses a lot on the developer experience. That’s what caught my interest and has kept me going, since there actually aren’t that much API details to remember.

Developing in Svelte

Start to play around with Svelte using the following commands, which effectively clones an example project setup:

  npx degit sveltejs/template new_app

The project setup is put in the new_app directory. Enter that folder and start developing like so:

  cd new_app
  npm install
  npm run dev

Visit http://localhost:5000 and open your editor of choice to take a look around of the files that produced the web application. Find src/App.svelte and make a change. It should immediately be reflected in the browser.

The svelte compiler is configured in rollup.config.js and src/main.js is the starting point for the application.

Components

Components in Svelte follows the “component tree” abstraction made popular by React. Creating custom elements that’s inserted into your regular HTML markup. Create a new file src/TimerButton.svelte.

<script>
  // javascript goes here
</script>

<style>
  // styling goes here
</style>

<button on:click="{handleClick}">+ 30 seconds</button>

Remove most of src/App.svelte and import the TimerButton component:

<script>
  import TimerButton from "./TimerButton.svelte"
</script>

<TimerButton />

By now, if your editor hasn’t shown you nice colors yet, it’s time to set it to highlight html and you should be good to go.

The timer button should be disabled for 30 seconds after clicked, so let’s add some logic to do that. It’s a simple interval counting down and we use curly braces to use variables and functions in the markup.

<script>
  let time = 0;

  setInterval(() => {
    // if time is 0 (or below?) stay 0, otherwise decrease by 1
    time = time <= 0 ? 0 : time - 1;
  }, 1000);

  // handler to refer to from the markup
  const handleClick = () => {
    time += 30;
  };
</script>

<style>
  button[disabled] {
    background: white;
    color: lightgrey;
  }
</style>

<button disabled={time !== 0} on:click={handleClick}>+ 30 seconds</button>

If copy pasted correctly, you should have a button which when clicked disables itself for 30 seconds. But it would be nice to show the count down as well. That’s easy to print in some more markup (try and do that now…). But I would like to show how that state can be handled by a store instead.

Stores

Our store will for this example be very simple. There are of course more complex variants (read about them here). Create src/TimeStore.js and fill it with these two lines:

import { writable } from "svelte/store"

export const timeStore = writable(0)

Our TimerButton.svelte should now be refactored to use the store instead of the local time variable. The subscribe part of the code seems somewhat boilerplatey, feel free to rewrite using an auto subscription.

import { timeStore } from "./TimeStore.js"
let time

setInterval(() => {
  timeStore.update(t => (t <= 0 ? 0 : t - 1))
}, 1000)

const handleClick = () => {
  timeStore.update(t => t + 30)
}

timeStore.subscribe(t => {
  time = t
})

We have now created a store and interacted with it using the update and subscribe functions. In fact, the API you need to learn isn’t much more than that. However, we just used a writable store. There are readable and derived stores as well, which we will not get in to more detail about here.

We will create a second component to show the decreasing time value which it will read from the store. This time we will use the much sleaker “auto subscribe” method to read the value. Create src/TickerView.svelte containing the following code:

<script>
  import { timeStore } from "./TimeStore.js"
</script>

<style>
  p {
    font-size: 50px;
  }
</style>

<p>{$timeStore}</p>

This component doesn’t do much more than showing the decreasing number from the store. It includes some CSS though. Styling with CSS in Svelte is isolated to the component that declares the style. Svelte does this by rewriting all style declarations with a unique CSS class. So CSS for a p in one component does affect any other components.

Summary

So far we’ve made one of the simplest applications possible. But believe me, the complexity doesn’t really grow when scaling up. From my experience complexity grows due to poor naming and stress. A framework can only go so far in staying away from the developer’s attention, and in the case of Svelte, I think it has a good level of abstraction.

There are many features in Svelte which we didn’t cover, for instance reactivity, events, bindings, animations 😲, component lifecycle hooks and much more. Since Svelte only brings along those features needed when compiling the code, there’s no need to prioritize away features with regards to bundle size (which other frameworks must compromise).

Resources

• Svelte Tutorial - the go-to interactive tutorial
• Sapper - an application framework made for Svelte

Craft Conf har det uttalade temat ”software delivery craft” och fokuserar på de metoder och verktyg som kan vara till gagn den enskilde individen, större organisationer och allt däremellan. Efter att tidigare ha besökt mer tekniskt inriktade konferenser så var det välkommet att få lyfta blicken en smula. Det här året lockades det med namn som Martin Fowler, Dan North, Dave Snowden, Mary Poppendieck och Bjarne Stroustrup. Bland talarna fanns även Göteborgsbekanta Emily Bache.

Återkommande teman i dragningarna var chaos engineering, skalbar arkitektur och Cynefin. Bland de bättre var Martin Fowlers och Birgitta Böckelers Cultivating Architecture och Randy Shoups Moving Fast at Scale, bägge en blandning av tänkvärdheter och sunt förnuft. Mary Poppendieck höll en underhållande presentation om hur det är att jobba inom Reliability Engineering, där hon delade med sig av sin långa, gedigna erfarenhet. Några av talarna kan återupplevas, med varierande ljud- och bildkvalitet, på Prezis Youtubekanal.

Överlag var Craft Conf en trevlig tillställning som höll till i en lite annorlunda miljö, i och kring ett av ungerska tågmuseets lokstallar, drygt en halvtimme med kollektivtrafik från centrala Budapest. Gissningsvis var det fler besökare i år än tidigare, det märktes att logistiken var lite underdimensionerad vid bland annat matserveringen. Man kunde promenera fritt bland gamla ånglok och vändskivor vilket var skönt ibland då det stundtals blev lite trångt inne i lokalen.

Sammanfattningsvis var Craft Conf en prisvärd konferens med intressant tema, med en gemytlig järnvägshistorisk inramning.

In this article I will describe BankID API features which developers should use to limit the effectiveness of today’s phishing attacks against BankID. I will also cover how QR codes can be used as a method for authentication/signing with mobile BankID and how it can improve security.

After reading this article, you will have learned different phishing techniques that exists and what you can do to limit their effectiveness.

Ordering shoes

Depending on which platform you initiate BankID on, the flow will be different.

Let’s assume we want to order a pair of shoes from supershoes.se on our computer. We pick our shoes, proceed to checkout, enter our address information and select mobile BankID as our signing method. We enter our personal identity number (PIN) and open the BankID app on our phone and sign.

What happened was that supershoes.se sent a signing order with our PIN to BankID using their REST API, informing that the accompanying PIN should sign this request. In this scenario, we expect the user to consume their signing order on a mobile device. I will later explain why this distinction is important. After we send this request to BankID, a special token called autoStartToken is created which is tied to our session. This token is returned to the user, depending on which BankID method is used.

The BankID API offers a requirement parameter which allows you to configure how orders should be created and verified. To configure an order to be limited to mobile BankID, set certificatePolicies in the requirement field:

"requirement": {    "certificatePolicies": ["1.2.752.78.1.5"]}

This restricts an order to only be consumed on mobile devices. The same can be done for other platforms. If it is not evident why it is beneficial to control how an order should be consumed, the following example will show why.

The autoStartToken

Let’s say supershoes.se implemented a member’s area page protected by BankID login, with the option to use BankID on file to authenticate. No personal identity number is technically required for this option, if you have multiple identities on your computer/phone, you will be prompted to select the appropriate identity.

Alright, we are sitting at our computer, we browse to the member’s area at supershoes.se and login by authenticating with BankID on file. What happens at this stage is that a special URL is returned to our browser which opens the BankID application automatically. The URL looks like this:

bankid://?autostarttoken=463e5661-33a9-4738-ad1e-6c5ef1d732ce&redirect=null

The local BankID application opens automatically because it has associated itself with the protocol bankid://. The interesting part is the autoStartToken parameter which contains the token value. This token is associated with your current session.

After your local BankID opens, you enter your credentials and successfully complete the identification (or signing). Now, let’s assume the developers at supershoes.se did not specify which platform the token should be limited to. This is means that even though you requested to identify/sign with BankID on file, the token you received can be consumed by mobile BankID on a different device. An attacker could generate a token meant for BankID on file and trick someone to authenticate themselves with the token on their mobile device.

The only thing an attacker needs to do is to send the following:

bankid://?autostarttoken=463e5661-33a9-4738-ad1e-6c5ef1d732ce&redirect=null

Which can of course be semi-disguised as an HTML link, like so:

<a href="bankid://?autostarttoken=463e5661-33a9-4738-ad1e-6c5ef1d732ce&redirect=null">Click me!</a>

Once the unknowing user clicks the link and identify using mobile BankID on their smartphone, the attacker will be successfully logged in as the user. Why this seemingly tiny detail matters is because most users today use mobile BankID which makes this scenario easy for an attacker to perform. Had the token been limited to only be consumed using BankID on file, then this scenario had not been possible. The only thing an attacker could do is to trick someone to identify with the token using specifically BankID on file, which is harder for an attacker to convince someone to do, since most people use mobile BankID.

AutostarttokenRequired

In the first example we ordered shoes from supershoes.se from our computer, entered our personal identity number and chose to sign with mobile BankID. If you have multiple mobile devices with your BankID identity installed, you could open any of those devices to sign the request, which is the purpose of mobile BankID.

Let’s explore another common scenario – supershoes.se has created their own app which you have downloaded from the Appstore to your smartphone. In order to use the app, you must enter your PIN and login in using mobile BankID. Since you are on your smartphone and trying to login with your smartphone, you would expect only your smartphone to be able to authenticate. However, as previously mentioned if you have multiple devices with your BankID identity installed, any of them could open the BankID app the sign the request.

This becomes problematic because an attacker could enter your PIN and trick you into signing. This is how most BankID scams are performed today.

But as you may suspect, there is a way to control if all your devices should be able to sign a BankID request or if it should be limited to the device that initiated the request. This is done by specifying the autoStartTokenRequired field in the API request when creating an authentication/signing order request.

"requirement": {"autoStartTokenRequired": true}

The option autoStartTokenRequired specifies that no other device will be able to sign the request. Only the device that initiated the request (your smartphone in this case) will get the autoStartToken and thereby be able to sign with BankID. This means we can make it harder for those who enter other people’s personal identity number and tricks people into signing with their mobile BankID. By specifying autoStartTokenRequired, only the attacker will get the autoStartToken. The attacker must then somehow transfer the token to the victim.

The problem is that we can’t use autoStartTokenRequired when ordering on our computer and signing with mobile BankID, because our mobile phone somehow needs to consume the autoStartToken. This is where QR codes comes into play.

Scan the QR Code

QR code scanning does not involve implementing a new technology or support a new protocol, it’s already supported! The QR code is just a visual representation of the URL containing the autoStartToken.

The only thing developers need to do is to convert the returned URL after sending an authentication/signing order request to BankID, to a QR code and instruct the user to scan it with their mobile BankID, that’s it!

We previously mentioned the autoStartTokenRequired option and its purpose to only allow the device with the autoStartToken to authenticate/sign an order request. This works great if you are using BankID on file on your computer/smartphone or mobile BankID on the same device. However, it will not work if you are using mobile BankID on different devices, since you often initiate the request on your computer and open the mobile BankID app on your phone. The token cannot be created with autoStartTokenRequired = True in this scenario. This is where QR codes shines.

The QR code is just a visual representation of

bankid://?autostarttoken=463e5661-33a9-4738-ad1e-6c5ef1d732ce&redirect=null

Which now means that the user can easily consume the autoStartToken and sign the request.

Which is the ingredient you need to authenticate/sign with BankID. Therefore, when offering to sign with mobile BankID on a different device, autoStartTokenRequired can be set to True if QR codes are used.

Conclusion

We have identified three possible flows using BankID

• BankID on file
• Mobile BankID – different device
• Mobile BankID – same device

To make current phishing attacks against BankID harder to perform, we can do the following:

• Set certificatePolicies to define which platform an authentication/signing order request should be limited to.
• To prevent our mobile BankID app to automatically activate when there is an existing authentication/signing request order present, we can set autoStartTokenRequired = True. Good for BankID on file and mobile BankID on same device.
• When using mobile BankID on different devices – set autoStartTokenRequired = True and enable QR codes. The user must scan the QR code presented on the device that initiated the order request.
• The user’s personal identity number should always be present for each order request. This limits the effectiveness of simply generating a token and sending it to random people, hoping that someone will sign using the token.

None of these features prevents phishing attacks against BankID. They only make today’s attacks harder to perform and requires additional technical skill from the attacker than just being able to call victims. If the attacker can trick a victim into clicking a link containing the autoStartToken, it will be possible to phish BankID users.

However, the point is to make the process more difficult for the attacker, which can be achieved by following the steps above.

BankID API documentation can be found here: https://www.bankid.com/bankid-i-dina-tjanster/rp-info.

Bonus question: Can you find the open redirection in the token URL? :)

Hösten 2016 föreslog jag, i den andan, att våra juniorkonsulter skulle ta sig an en app för japanskainlärning. Utvecklingen har skett som ett “riktigt” projekt, där slutmålet, en webbapp, är viktigare än att deltagarna utvecklas. D v s det har inte varit ett projekt för att lära upp juniorkonsulter, utan ett projekt för att ta fram en app för japanska, och projektmedlemmarna kan inte undvika att lära sig mycket, trots, eller snarare, tack vare, att lärande inte är i fokus.

Projektet har körts i fyra omgångar men tar nu ett uppehåll och det är dags att summera. Hur har det gått?

Bakgrund till projektet

Våren 2016 började jag läsa japanska på Göteborgs Universitet, och började leta efter appar som stöd för min inlärning. Det finns ganska många olika appar och webbsidor för språkinlärning, men de är oftast inte anpassade för japanska, med sitt komplicerade skriftsystem. Dessutom fanns inga alternativ om man vill lära sig från svenska till japanska, åtminstone inga som jag kunde hitta.

Som svenskar har vi en stor tillgång i att de flesta av oss kan prata två språk ganska bra, engelska och svenska, och de flesta av oss har lärt oss grunderna i fler språk. I japansk undervisning utnyttjas det mest genom att engelsk litteratur används istället för att ta fram svenska alternativ. Jag tror att det ändå är bättre om man lär sig japanska direkt från svenska. Det blir en onödig extra kognitiv belastning att gå via engelska. Engelskakunskapen skulle däremot kunna utnyttjas som förstärkning och precisering. Ett konkret exempel: Sumu är ett verb som kan översättas till live på engelska eller att bo på svenska, och genom att lära sig båda översättningarna får man en bättre förståelse för vad sumu egentligen betyder.

Det här var inspirationen till appen Gakusei. Målet mer specifikt är att appen ska vara ett stöd för svenska studenter som läser japanska på ett universitet. Ingående komponenter skulle kunna vara t ex glosförhör, grammatikövningar, skrivövningar, men också mer generella saker, som statistikinsamling och lärarstöd. Webbappen ska vara open source.

Utveckling

Teknikstacken ser ut som något vi skulle kunna stöta på hos våra kunder, en traditionell backend med en lite nyare fronted. Spring Boot och React landade vi i, men det hade lika gärna kunnat vara t ex JEE och Angular. Mestadels har vi använt Scrum. Inget konstigt för en it-konsult med andra ord.

Första kullen färdigställde de första versionerna med bl a glosförhör, inloggning, statistikinsamling, talsyntes, flashcards, teckeninlärning. I februari 2017 visade vi upp Gakusei för lärare och studenter på Göteborgs Universitet, vilket skapade intresse för appen vid Göteborgs Universitet, Högskolan i Dalarna, och Hvitfeldtska Gymnasiet.

Gakusei har ända sedan 2017 varit öppet för vem som helst att använda, och lärare och studenter har testat och kommit med värdefull feedback. Dock har jag hittills varit den enda fasta användaren, och andra kullen arbetade mycket med driftsfrågor, samt att ta bort hinder för att använda Gakusei. T ex gjordes förstasidan om från början, HTTPS infördes, och servrarna konfigurerades med automatisk backup. Dessutom togs ett administrationsverktyg för dataredigering fram.

Arbetet fortsatte våren 2018 med nytt utseende på lektionssidorna, och smart inlärning (spaced repetition). Teckeninlärningen gjordes om så att den gick att använda i praktiken, tidigare hade den varit för otillförlitlig. Så till sommaren hade vi en applikation som var konkurrenskraftig men fortfarande lite för buggig.

Den fjärde kullen har fokuserat på att förbättra stabilitet och utseende. Några kända buggar återstår, men i stora drag känns grundfunktionaliteten väldigt stabil. Vi har också gjort analysverktyg m h a ELK-stacken, som vi ska använda för att finjustera inlärningsfunktioner, hitta problemområden och så vidare. Parallellt med detta har jag skapat data, ord- och kanjilistor m m, och idag täcker vi de tre första terminerna ganska väl.

Resultat

Jag tycker att Gakusei nu är konkurrenskraftigt jämfört med de vanligaste engelskspråkiga alternativen och en app vi kan vara stolta över.

Hur har det då fungerat som inkörsport till arbetslivet? Förvånansvärt bra, projektmedlemmarna har fått erfarenhet och självförtroende.

Gakusei var ett perfekt projekt för mig som var ny på arbetsmarknaden. Det var skönt att på ett prestigelöst sätt få lära mig hur det är att jobba i ett riktigt projekt tillsammans med andra som befann sig i samma situation. Dessutom så fick jag direkt nytta av de ramverk som Gakusei använder då samma teknikstack användes på mitt första uppdrag

Joakim Danielsson

Nu avslutar vi Gakusei-projektet och Kits lämnar över produkten Gakusei till mig för vidareutveckling och förvaltning. Kommer Gakusei att bli en produkt att räkna med framöver? Det återstår att se, men det finns en stabil grund att stå på, och jag har stora förhoppningar om framtiden!

Gakusei var ett bra projekt att jobba i där man fick använda tekniker man hade tittat på under utbildningen i ett större sammanhang

Joella Johannesson

Vi har kört fyra vändor hittills, och det hade vi förstås inte gjort om det inte hade fungerat, och vi fortsätter med konceptet nu i vår, men med en ny produkt. Håll utkik efter LogLady, ett nytt verktyg för programmerare!

Gakusei finns på https://gakusei.daigaku.se
Följ utvecklingen av LogLady på https://github.com/kits-ab/LogLady

Ball mazeing for dummies

Controlling

We broke out the 3D-printer, modified some stepper stands (creative commons, made by adamyelland download drawing), bought some servos (Luxorparts S3003) and got to soldering! We attached the whole thing to a Raspberry Pi 3 which in turn steered the servos and listened to the NS30 over Bluetooth (using python, following this guide).

At first, we wanted to use the gyro function to steer how much the servos should move but for some reason we never got it to work…

So, we moved on to using the sticks. Left stick for up/down, right one for left/right. It was not the most natural way to steer so the first couple of times playing most struggled slightly, just as intended! The last piece of our over-engineering was how to time each race from start to either finish or failure.

Detecting the ball and measure time and length of the game

We opted for a webcam that kept track of the ball as it moved through the maze, giving points for each zone cleared and ending the game when it lost sight of the ball. Recognizing objects using computer vision is a somewhat mystified process. Similar to how a person who is not a programmer perceives how applications are made, even a programmer may find that they don’t have a clue on what actually happens to “recognize” things using a camera and some code.

One way of doing video/picture analysis is using machine learning, for example Googles TensorFlow. You take a picture (or video stream), feed it to a “magical tool”, and out comes data saying what it is, and perhaps also where it is on the picture.

We went for a more special purpose solution using OpenCV.

OpenCV is an open source computer vision library, written mostly in C++, it effectively allows you, as a developer, to modify an image as much as it lets you measure things. The steps we took was:

• Modify: Capturing the source picture and shrinking it to a smaller resolution.
• Modify: Removing all the Blue and Green in a picture, keeping only the Redness.
• Modify: Replacing a range of redness with a single, solid, red color.
• Measure: Get all matching pixels where neighboring pixels are also red.
• Measure: Finding the biggest source of red by applying regular programming arithmetic.

While the example above is intentionally convoluted, the reality is that this is how we detected the ball in the maze. :-)

In a five day conference there are a lot of topics covered. There where over 100 sessions and even more labs where you could actually get access to over 1 000 Apple engineers. I managed to go to about a quarter of the sessions and visit a handful of labs and in this post I’ll try to summarize my impressions, talk about how it may effect us developers and link to the best talks.

Machine Learning and Augmented Reality

Last year Apple introduced Core ML and ARKit and to be honest I was not really that interested. ARKit lacked a lot of stuff and you still had to train your machine learning models using other tools before you could take advantage of Core ML. After this year’s talks though, I’m really impressed.

The first piece of the puzzle is Create ML, a simple way to to augment prebuilt models from Apple with your own custom data. You can use images, text or tabular data and it’s ridiculously easy to get started. For images you can start by putting a lot of images of apples in a folder called apple, oranges in a folder called orange and bananas in a a third folder. Then you can use Swift Playgrounds to pass the images to Create ML or just write a simple script like this:

#!/usr/bin/swift
import Foundation
import CreateML

// Specify Data
let trainDirectory = URL(fileURLWithPath: “/Users/Joakim/Desktop/Fruits“)
let testDirectory = URL(fileURLWithPath: “/Users/Joakim/Desktop/TestFruits“)

// Create Model
let model = try MLImageClassifier(trainingData: .labeledDirectories(at: trainDirectory))
// Evaluate Model
let evaluation = model.evaluation(on: .labeledDirectories(at: testDirectory))
// Save Model
try model.write(to: URL(fileURLWithPath: “/Users/Joakim/Desktop/FruitClassifier.mlmodel“))

Now you got a trained model that you can drag into your project and you are ready to recognize fruits in your images. Text and tabular data can be trained in the same way. I can think of a lot of cases where this could have improved previous projects I’ve been involved in and I hope I’ll get to use it in the future.

With machine learning in place we can turn to an application of machine learning and that is augmented reality. Apple introduced ARKit last year and this year they added image, face and object tracking which means you can both recognize these in the real world and track them around as they move. You should really check out this video to understand how it works but I was able to try this for myself and it’s actually really nice.

They also added support for persisting the AR world as you build it and support for multiple users in the same world which makes it possible to create really fun experiences. At WWDC they ran an AR tournament around the game SwiftShot. The entire game is open source so you can download it to play or learn more.

Universal Scene Descriptions

If games and object recognition is not your thing, how about shopping for bags online and actually being able to put it on your back to see how it looks? That will not be so hard to do in the future.

If, in addition to an image of the bag, you create your bag as an AR scene you can now store this in a .usdz file. This is an open file format that Apple created in collaboration with Pixar. When you’ve created this file you can link to it, just as as you normally do on the web, and users can click on it to show the bag in the augmented real world and do whatever they want with it.

Creating these scenes will obviously be quite hard but Adobe showed a preview of project Aero that will make this much easier.

This may have been one of the least appreciated announcements this year and whenever you create your next e-commerce solution I will call it a fail if it doesn’t include AR.

Siri Shortcuts

Building on the Machine Learning theme shortcuts provide a way for developers to surface actions that a user do frequently to Siri to let Siri learn the behaviour of the user. With this knowledge Siri can surface these actions as shortcuts on the lock screen, in spotlight or in the Siri watch face on the Apple Watch as they become relevant (based on time, location and user behaviour). Contrary to other companies, Apple doesn’t collect this data on their servers and instead it all happen on-device and to me this makes it much less creepy but to be honest, probably not as good.

These shortcuts can also be triggered by voice if the user assigns a trigger phrase to them. This trigger phrase can even be used on CarPlay or the HomePod. This finally opens Siri to all developers which is really good. Unfortunately the trigger phrases are static so we can’t pass parameters the same way we can to Alexa for instance and this makes this feature way less attractive but it’s a first step and I would not be surprised to see this added in a future release.

If your app already uses NSUserActivity you can expose it to Siri shortcuts by simply setting userActivity.isEligibleForPrediction = true and if you want more control and the ability to run the commands using your voice in the background you can use the more advanced intent api.

Finally there is a Shortcuts app that can tie all of these shortcuts together. The shortcuts can be scripted, combined with calls to web services and we can even assign a trigger phrase to them. This means that for the first time since the iPhone was introduced, we finally have built-in automation on iOS!

Notifications

In the keynote Apple showed grouped notifications and got huge applause. The changes to the notification system was much bigger though, it really got a complete overhaul. Notifications can now be more dynamic, have custom actions and if the notification provides a custom UI, using content extensions, it can now be fully interactive. This means that if a user receives an offer as a push notification the user can now interact with that notification and choose what to do with the offer right there without opening the app.

Apple is also making it way easier to manage notifications as the user receives them. This means that the user will now be able to turn notifications off right from the notification so if you abuse the system, by sending too many or irrelevant notifications, I’m pretty sure that user engagement will go down over time.

Performance, performance, performance

Performance really was the theme of the conference and if you run the beta you will not be disappointed. You can really see that the platforms have grown up and you don’t have to focus on how to put stuff on the screen anymore and instead you can focus on how to do it really really fast. This includes everything from the network stack up to scrolling in table views, from persistence in Core Data to how image assets are compressed.

I learned so many great tricks and this really is where native development shines. I’ve never been a fan of cross platform tools such as Electron or React Native and this is one reason. I realize that in many situations this doesn’t really matter but if you want to make your product the best it can be, there really aren’t any choice.

The conference

Besides the big stuff there obviously was a lot of “small” stuff as well. NFC for Wallet Passes, a new Mac App Store, Dark Mode for macOS, a sneak peek of UIKit running on macOS, WebKit running on the Apple Watch and a whole lot more.

To summarize, I was really impressed with both the content of the conference and the conference itself. The organization around the keynote was a mess but besides that, everything worked great.

There where a lot of great sessions but these are my favorites:

• What’s New in ARKit 2
• Designing Fluid Interfaces
• Platforms State of the Union
• Strategies for Securing Web Content
• Deliver an Exceptional Accessibility Experience

After visiting a few labs I realize, what everyone have been telling me, that this is the real benefit of the conference and I kind of regret not going to more but I guess I can do that the next time I’ll get to go in six years. I really hope it won’t take that long though, because as an Apple fan, this was without a doubt the best conference experience I’ve ever had and I wish can can go next year.

For the last year I’ve been working on a project where we use this kind of architecture to create an IoT platform and not only have this made backend development fun for me again but it have fundamentally changed how I think about creating software. In a series of posts I’m going to take you through the experience of building a full application. Let’s start with an introduction.

What is serverless?

First of all, serverless is a really bad name. Not only because it both describes an architectural pattern, a specific framework and the company that makes that framework but also because it’s not even true. There is of course always a server somewhere so maybe serveradministrationless would be a better name but that’s not as catchy so let’s stick with serverless for now.

I don’t think there’s a strict definition of what serverless is and there have definitely been several services in the past that you might call serverless but what really caused serverless to take of was when people started using the term to talk about “Functions as a Service”. The idea is that as a developer you should have full control of the code behind your application but that is all you need to worry about. How the functions are actually executed is not important. Just focus on creating beautiful code and it will be run and scaled for you automatically.

A typical serverless function can look like this:

module.exports.hello = (event, context, callback) => {
  const response = {
    statusCode: 200,
    body: JSON.stringify({
      message: "Hello World! You're awesome!"
    })
  }

  callback(null, response)
}

If you can see through the weirdness of JavaScript this looks like a normal function that returns a Hello world message, why is this such a big deal?

As I hope this series will show you this turns out to be a great way to structure your application but what’s even better is that when you deploy this function it will cost you absolutely nothing until it’s actually used. If your service suddenly gains traction and gets widely popular it will scale automatically so all requests will be served super fast and you will only pay for the actual execution time.

Still not convinced? Let’s try it for real to give you an idea of what to expect.

Getting started

Just as pretty much every cloud provider has its own solution for running containers, many of them are starting to gain support for serverless architectures. I’ll get back to this in a later post but for now I’ll be focusing on AWS’ implementation called Lambda just because it’s the most mature solution and it also happens to be the one that I’ve been working with for the last year.

Preparations

Before we start you need to prepare a few things. You need to install Node.js version 4 or or later. You can write your code using other languages as well but the tool that we are going to use requires Node.js. You also need an AWS account. There is a free tier available for AWS and since Lambda is included in this you can do a lot before you need to pay any money.

The final step is to acquire the access key to AWS to deploy your functions. You should probably create a separate account and limit its permissions but to keep things simple we are going to use your root credentials (see this guide if you don’t want to do that). The access key can be found if you login, choose My Security Credentials from the top right menu. Choose Access Keys and Create New Access Key. Save this information, you will need it later.

Serverless, the framework

Now that we’re prepared, we can start creating our application. If you’re impatient, you can login to the AWS console, go to Lambda, choose Create a Lambda function, click through the wizard and paste the code above. Press Save and Test and it will run. That’s cool but not a very practical way of writing real applications so for this series I’m going to use a framework called Serverless.

Run the following command to install it:

npm install -g serverless

Now you need to allow Serverless to access your AWS account. Run the following command but substitute <YOURKEY> and <YOURSECRET> with the credentials you saved earlier.

serverless config credentials --provider aws
	--key <YOURKEY> --secret <YOURSECRET>

Now you’re ready to create your first project. I’ll be using the template nodejs in these posts but you can use python, java-gradle, java-maven, scala-sbt or csharp if you want to. To create a project in the current folder run the following command:

serverless create --template aws-nodejs

This will create a normal Node.js project and install its dependencies. The interesting parts can be found in handler.js that contains the actual function that we want to run and the file serverless.yml that contains the configuration that tells AWS how to deploy the function and how to trigger it. How should the function be triggered?

Events

Even if functions are the heroes of serverless architectures they still need to be triggered somehow. The trigger can be a lot of things; a message on a queue, an event from an IoT device or maybe another function. I’ll get back to these in a later post but for now we are going to use a normal HTTP request to trigger the function.

Open the file serverless.yml and locate the events section. Uncomment the following lines to instruct AWS to setup API Gateway to provide the GET endpoint /hello that calls the function.

events:
  - http:
      path: hello
      method: get

Next let’s deploy and run this.

serverless deploy

This will take a couple of minutes since it creates a new stack on AWS and deploys the function. The next deployment will be much faster.

Now open a browser and paste the url from output into a browser. Congratulations, you’ve just created and deployed your first serverless service and exposed it to the world on an HTTP endpoint.

What just happened?

Let’s dive into what happened. Serverless created a new stack for you in your AWS account. A stack is like an environment and since you can have multiple stacks you can create one for development, one for testing and one for production or why not one stack for each pull request. Next it deployed the function as a Lambda and configured API Gateway so that when you call the GET endpoint it calls the Lambda. It also created the neccessary roles for the services to communicate with each other.

Serverless doesn’t have a magic wand to do this, instead it uses CloudFormation which is the solution that AWS provides to automate deployments. CloudFormation is quite complicated though so Serverless makes this much easier.

You can deploy your code to a new stack by adding the --stage parameter (the default stack is dev).

serverless deploy --stage prod

After you run this command your AWS environment will look like this.

That’s it. Now you are ready to develop your application. If you want you can call the Lambda from the command line using serverless invoke --function hello and if you want to see the logs that it produces you can add a console.log statement to the handler, deploy it run it and then call serverless logs --function hello. When your application grows you can deploy a single function using serverless deploy function --function hello.

Where to go from here?

This was an introduction to serverless architectures and the Serverless framework and even though we’ve just created a service that scales automatically, that only costs when it’s invoked it is still a really boring application. In the following posts I’ll be showing you where to go from here. How to structure your application, how to add a web frontend to it and maybe connect it to some real devices as well. Stay put for more.

First off, what is a web browser?

A web browser is a computer program which lets the user view and interact with web pages. Technically, a browser (i.e. Google Chrome or Firefox) is of a computer program that runs natively on the current operating system. That program handles things like window management, tabs, bookmarks and more. It also uses a “rendering engine” to calculate what should be shown in the greater part of the interface. The browser is provided a url (usually the user writing in the address bar or clicking a link) which it passes to the rendering engine along with a surface that is used to paint the interface on.

Historically browsers tend to do the rendering task somewhat different. Which is a subject of its own, but let’s stick to the subject and move on.

Responsive web design

Responsive web design is, according to Wikipedia “an approach to web design aimed at crafting sites to provide an optimal viewing and interaction experience — easy reading and navigation with a minimum of resizing, panning, and scrolling—across a wide range of devices (from desktop computer monitors to mobile phones)“. The practical translation for a web developer is that we want complete control of the screen area and the interface we put on it has to have the right size for interaction and viewing.

But mobile and desktop screens have different size and ratio and they have different types of input devices. This implies that interfaces need to be customized for the target screen and input device.

Show me the code

Let’s dive right in and look at some code. Assume the following markup and styling for a web page:

<html>
  <head>
    <style type="text/css">
      #something {
        width: 35%;
        background-color: red;
      }
    </style>
  </head>
  <body>
    <div id="something"><p>Hello</p></div>
  </body>
</html>

This will result with the div #something to have the width of 35% of the parent element, <body>. The <body> element will take up 100% of the width of the <html> element. Then what, how wide is the <html> element?

The viewport

The uppermost building block of a web layout is called the viewport. It’s what contains the <html> element. It’s the outer limits for the rendering engine to work with.

When dealing with responsive web design, control of the viewport is what really enables us to produce interfaces for all screen sizes.

Let’s invent the mobile internet

Image you have the task to make internet work nice on mobile screens. There are neither previous mobile browsers nor web pages optimized for mobility. To make the “mobile internet” gain any popularity, it surely needs to work with every existing web page out there, or at least close to. So before even trying to make responsive web design, we need to address existing content first.

How existing web pages work

Web pages are styled using fixed pixel sizes, percentage expressions and other measurements. Consider a menu on the side of the page which is styled using a percentage width. On a mobile screen that might end up in such a narrow band that none of the text fits. (You may notice that I omit ‘height’, that is because the height of a web page is most often variable and is not as important when dealing with responsive design as the width.)

On mobile the rendering engine needs to believe that the target area is more pixels wide than it physically is. So the interface gets painted to more pixels than the phone has. The canvas is then zoomed out to show the complete interface on the screen.

As you might have guessed, we need to tamper with the viewport. The viewport would logically get the width of the mobile browser, thus the physical width of the mobile device. But it is not, it gets another width decided by the creator of the browser. This width differs between browsers and device vendors, but span 768-1024px. If a mobile browser tells the rendering engine that it is 980px wide it will render the example #something div 35% of 980px = 343px wide. The interface drawn for 980px will then be zoomed out to fit the mobile device. This way existing web pages will render correctly to mobile browsers, but we haven’t yet touched any responsive behavior.

A note on higher resolutions

Recent models of computer screens and mobile devices often have higher resolution than prior models. More dense pixels would logically end up in interfaces being drawn at smaller sizes than before. But we know that they are not, web pages didn’t shrink to half the size when the Mac got its retina display. The abstraction we look for is called devicePixelRatio.

Try and type in devicePixelRatio to your browser developer console, what comes out? On recent Macbooks it says 2, on older it says 1. It can be any fractional number though. This is a number that affects the width communicated to the rendering engine. For a screen that has a devicePixelRatio = 2 the number of physical pixels gets divided by 2 before going in to the rendering engine. That way a browser that takes up 1400 physical pixels only communicate 1400 / 2 = 700px to the rendering engine. That’s why CSS that targets 700px gets interpreted the same way without you having to manually deal with screen resolutions.

Imagine some years from now, where no device have devicePixelRatio = 1 any more. It will be weird to write CSS targeting pixel sizes that no device have.

What sets mobile apart from desktop?

Let’s introduce some proper names for the things we’ve just talked about. On a desktop browser there is the viewport, which has the same width as the browser window, (although altered at higher resolutions). On mobile though it’s slightly more complicated.

Layout, visual and ideal viewport The rendering engine operates on what’s called the layout viewport and the physical pixels of the device makes the visual viewport, (The media queries we declare in CSS targets the layout viewport).

The third and last viewport, the ideal viewport, is an abstract notion of the best layout viewport for a particular device. The ideal viewport might as well be physical pixels / devicePixelRatio, but in many cases it differs slightly from that. Luckily the developer has an easy way of using the ideal viewport:

<meta name="viewport" content="width=device-width,initial-scale=1" />

This declaration is the meta viewport tag and it goes inside of the <head> section of the HTML. The width=device-width command tells the rendering engine to use the ideal viewport as layout viewport when it renders the web page. There are more options to this meta tag, summarized by Peter-Paul Koch at Quirksmode

Where to go from here

By now you hopefully have the understanding of why media queries work the way they do and a little bit of history about the challenges with web development for mobile devices. This short article does not cover the actual use of media queries, although I provided some good links to further reading and more comprehensive guides to that.

• Quirksmode - Mobile
• Apple - Supported meta tags: viewport
• CSS-TRICKS - CSS Media Queries & Using Available Space

Välkommen till kits.se

Som vanligt återstår mycket att göra. En del texter saknas och andra behöver förbättras. Någon layout kanske inte fungerar i alla webbläsare men det är en 1.0 i alla fall.

kits.se kommer givetvis vara ett av våra ansikten utåt men dessutom tänker vi oss att det kommer vara en sida där vi experimenterar med nya tekniker för att bygga modern webb och skriver om vad vi kommer fram till. Allt detta finns redan idag tillgängligt på GitHub så om ni vill rapportera ett fel eller bara är nyfikna så är ni välkomna. Vi kommer skriva mer här på bloggen om hur sidan är byggd inom kort.