Home

BICC Scheme

By Blackbrick

The BICC Scheme is the Blackbrick Input Color Coding Scheme. It is a specification for coloring HTML input elements on web pages to indicate the validity and publication status of the data.

Invalid data is indicated by the use of a red border around the input element. You can read more about data validity.

The publication status indicates how the input data will be used. There are six levels of publication status, each more secure than the previous.

The publication status color codes are:

Unknown White where the publication status has not been specified.
Public Red where the data will be publicly available.
Insecure Orange where the data may be transmitted over an insecure network.
Shared Yellow where the data will be stored in a shared database.
Private Blue where the data will be stored in a database that only you have access to.
Secure Green where the data is encrypted or local.

Table of Contents

Data Validity

Invalid data is indicated by a red border around the input element.

Invalid Example

Text Box
Text Area
Radio Buttons

Check Box
Select Dropdown
Select Listbox

Publication Status

A publication status is a promise about how data a user enters via a web form will be used. The publication statuses are progressively stronger guarantees about how data will be used. When designating an input element's publication status you should pick the weakest publication status that you can. Details follow.

Unknown

The publication status of this data is unknown or otherwise undisclosed. That means you should expect the worst and assume the data could be public.

Unknown Example

Text Box
Text Area
Radio Buttons

Check Box
Select Dropdown
Select Listbox

Public

The publication status of this data is public. That means that it might be included on public websites or in other publicly accessible publications.

Public Example

Text Box
Text Area
Radio Buttons

Check Box
Select Dropdown
Select Listbox

Insecure

The publication status of this data indicates that while the data is not published publicly it may be transmitted or made available over insecure networks and protocols.

Insecure protocols include email, HTTP and Wi-Fi. If this data will ever be included in an email, sent over HTTP (not HTTPS), accessed via Wi-Fi or otherwise transmitted via a clear-text or compromised protocol then the data will be classified as insecure.

Insecure Example

Text Box
Text Area
Radio Buttons

Check Box
Select Dropdown
Select Listbox

Shared

The publication status of this data indicates that it will never be made publicly available nor transmitted over an insecure network. However, it will be stored in a database that other authenticated users are authorized to access.

Usually the service provider has access to such data and in some circumstances you will be able to nominate others who you would like to share your data with.

Shared Example

Text Box
Text Area
Radio Buttons

Check Box
Select Dropdown
Select Listbox

Private

The publication status of this data indicates that it will never be made publicly available, transmitted over insecure networks, or shared with others. If it's designated as private you are the only user authorized to access the data. See also the note about legal disclosure.

Private Example

Text Box
Text Area
Radio Buttons

Check Box
Select Dropdown
Select Listbox

Secure

The publication status of this data indicates that it will never be made publicly available, transmitted over insecure networks, or shared with others. Further, such data will never leave your computer. If the data needs to be stored in a server it will be encrypted on the client before it is sent to the server.

It's important to understand that if the user's computer is insecure then even the data with this status is insecure. For example the user might be using a machine with a key-logger or virus installed. Data designated as 'secure' is only as secure as the user's computer.

Secure Example

Text Box
Text Area
Radio Buttons

Check Box
Select Dropdown
Select Listbox

Accessibility

When implementing the BICC Scheme it is important to provide additional support for the disabled. People who are color blind can't see the difference between the color codes and nor can those who are blind. For this reason when implementing the BICC Scheme color codes you should also include a statement with a link to details about the publication status next to or below each input element (typically along with an explanation about the data requirements).

For example:

This data is public.
This data is insecure.
This data is shared.
This data is private.
This data is secure.

Notes on Interpretation

When selecting which publication status levels to support we tried very hard to make sure that it was simple to understand objectively if the publication status met the criteria.

For example 'unknown' is easy to understand as it means that no indication is made about the publication status.

Similarly 'public' is easy to understand, your data might be included on public websites or published elsewhere.

The 'insecure' publication status is a little bit trickier. If the data is ever included in email or transmitted over an insecure network (such as a Wi-Fi network) then it definitely meets the insecure criteria. But it's harder to determine if that will necessarily happen. Also, if the data is transferred over a LAN (such as between a web server and a database) then it is not considered insecure for our purposes although in practice it might be.

For our purposes data on a wired LAN (such as Ethernet) or a VPN is not considered insecure as it's running over a private and relatively secure network. If you don't trust your networking environment is secure you can err on the side of caution and designate this data as insecure.

The 'shared' publication status is also a little bit tricky. Generally if the data is stored in a database operated by the service provider, and is not sent over any insecure networks, then the data is considered shared. However, if the service provider is providing storage services for the user where only the user typically has access to their slice of the data then the publication status might be upgraded from shared to private, even though the systems administrators of the service provider might technically be able to see the user's data in practice they undertake not to do such a thing. In that case it is acceptable to upgrade the publication status to from 'shared' to 'private'.

As a general rule if you're operating a web service for your users where you control or access the database you should designate your data as 'shared'.

The 'private' publication status indicates that the data is stored in a database that only the user has access to. As noted above some systems store data in their databases for the user. The best bet if you're storing data on behalf of users is to use the 'shared' publication status. However if you feel confident representing to the user that you won't examine the content of the data they store in your service nor share that data with anyone else (except to comply with law) then maybe you could designate it as private.

The 'secure' publication status is the strongest guarantee you can make about data. This is easy to understand. The data must never be transferred off the user's computer except if it has been encrypted first. That means if you're running a website you need to encrypt the data in the browser before sending it to your servers using a client-side JavaScript encryption library with a secret key provided by the user.

If the data is encrypted or hashed by the server it cannot be designated as secure. So hashed passwords for instance must be designated private, not secure. Only data encrypted on the client-side is considered secure.

Generally when designating publication statuses it is best to be conservative. A good rule of thumb is that if there is any doubt then pick the less secure option.

Access by Law Enforcement

Some jurisdictions have laws that require service providers to cooperate with law enforcement and other agencies. In the case where the service provider is required to hand over data to comply with law the designated publication statuses do not apply.

Technical Specification

Following are technical details concerning how to integrate the BICC Scheme with your website.

The Stylesheet

The first thing you need is a copy of the BICC Scheme stylesheet, which you can download.

You include the stylesheet in your web page with this HTML:

HTML Class Attributes

Use the following HTML class attributes to designate input data publication status. There are a bunch of synonyms. For example, bicc-1 and bicc-red both indicate public publication status. You only need to use one HTML class attribute, use the ones it's easiest for you and your team to remember or understand.

Data TypeHTML class attributes (pick one)
Unknown bicc-0, bicc-white, bicc-unknown, bicc-undisclosed
Public bicc-1, bicc-red, bicc-public
Insecure bicc-2, bicc-orange, bicc-insecure, bicc-network, bicc-email
Shared bicc-3, bicc-yellow, bicc-shared, bicc-database, bicc-db
Private bicc-4, bicc-blue, bicc-private, bicc-user
Secure bicc-5, bicc-green, bicc-secure, bicc-encrypted, bicc-local
Invalid bicc-invalid, bicc-error

HTML Input Elements

HTML elementWrap in divMultiple Options
Text BoxNoNo
Text AreaNoNo
Radio ButtonsYesYes
Check BoxYesNo
Select DropdownYesYes
Select ListboxYesYes

HTML Element Wrapper

Some user input controlls are comprised of multiple HTML elements. For example radio buttons and checkboxes include the input element and a label for that element.

Other HTML elements can't be styled reliably, for instance the background color on 'select' elements.

For elements such as the above it is best to include the elements in a containing 'div' element, and apply the BICC Scheme styling class to the containing 'div' element.

For example with radio buttons:

Or an example with a dropdown:

Multiple Options Support

Some HTML input elements allow for the selection of a number of options. It is possible that some options are treated differently than other options. For example if the user selects option A that is stored privately, but if they select option B that is shared.

In cases where you need to support multiple publication statuses you do the following:

  1. Place the input elements in a containing div with the weakest class. From the example above option A is private and option B is shared so the weakest class is bicc-shared.
  2. Style each option with it's appropriate class. From the example above the HTML option element for option A will be styled bicc-private and the HTML option element for option B will be styled bicc-shared.

For example:

Which looks like this:

The same technique can be applied to radio buttons.




Invalid Input Examples

If you're curious about what input controls look like for invalid data when using the BICC scheme you can see the results on the error examples page.

Extra CSS

You might want to tweak the provided CSS to support better margins, padding and borders. If you think you can help make the default stylesheet better then please do let us know at: support@blackbrick.com.

Back to Top

© Copyright 2014 John Elliot V et al.