--- layout: archive title: Zulip Chat Archive permalink: /stream/116395-maths/topic/quotient_module.20breakage.html ---
import data.set.basic import linear_algebra.quotient_module example (R : Type*) (S : set R) [ring S] : S := begin exact (4 : S) end /- maximum class-instance resolution depth has been reached (the limit can be increased by setting option 'class.instance_max_depth') (the class-instance resolution trace can be visualized by setting option 'trace.class_instances') state: R : Type ?, S : set R, _inst_1 : ring ↥S ⊢ ↥S -/
What is going on here? If I remove the import of linear_algebra.quotient_module
then this compiles fine. @Chris Hughes you thought about quotient module instances maybe -- do you know how to diagnose these things?
Related -- I have to ask here because I cannot diagnose the issue myself. I cannot read the trace.class_instances
output and I would really love to be able to. For what it's worth, just before it chokes it looks like this gist (and it's quite funny, manifestly something has gone wrong and it's a nice change from the usual, it's not a loop, it's a recursive hell).
https://gist.github.com/kbuzzard/2582db6593c7b7467f3e0020909af467
nice picture
Could you give a more realistic example?
Is R actually a ring and S a subring?
I don't understand why that would compile. If S is empty, it's trivial to get a contradiction from this.
Also note I had to modify stuff like this recently in the perfectoid project
There's nothing wrong with the statement of the theorem. It is a set with a ring structure, which is therefore nonempty and has a 4
As usual, modules are acting up because of the search for a ring instance
Chris : you're happy with (x : nat) (h : x > 4)
, right? But if x was 2 it's trivial to get a contradiction from this.
As long as it's a nonempty set there is a ring structure on it and a 4
and being a ring implies it is nonempty
Patrick -- it was trying to fix up the perfectoid project which led me to this. We need p in R^o for the definition to be OK. The statement that p divides something in R is vacuous because p is a unit in R -- R is like Q_p and R^o is like Z_p
I don't think the offending instances are in quotient_module
. Do you get the same problem with algebra.pi_instances
and algebra.module
?
anyway this is yet another problem that will be solved by my refactor
OK, I can definitely wait. I was planning on spending tomorrow thinking about the perfectoid project in a top-down way; this issue came up because the definition of a perfectoid ring is currently broken :-)
I'm having a day off real life tomorrow; my last day off for a while.
Patrick -- it was trying to fix up the perfectoid project which led me to this. We need p in R^o for the definition to be OK.  I fixed the compilation error but I was really unsure I didn't change the maths
I'm having a day off real life tomorrow; my last day off for a while.
Do you mean you'll have a Lean day or a no-Lean day?
anyway this is yet another problem that will be solved by my refactor
Do you have any estimation about when this refactor will be ready for use?
I am going to have a Lean day, but it's a bit cheeky -- I should really be doing other things.
Do you have stuff you can do without modules? Do you want to have fun with uniform spaces?
ha ha, I have been working from the bottom up during the little time I've had over the last month or so. I was going to try defining the presheaf on Spa(A), sorrying whatever I couldn't do.
Great!
It gets my vote
{% endraw %}Last updated: Apr 24 2020 at 19:02 UTC


--- layout: post title: "NY bans trans fat" ---
The Board of Health voted Tuesday to make New York the nation's first city to ban artery-clogging artificial trans fats at restaurants -- from the corner pizzeria to high-end bakeries. The board, which passed the ban unanimously, did give restaurants a slight break by relaxing what had been considered a tight deadline for compliance. Restaurants will be barred from using most frying oils containing artificial trans fats by July and will have to eliminate the artificial trans fats from all of their foods by July 2008.Check out the whole article. Link courtesy of Simon.


Accident
Pregnancy
Other
Contact Information :
Email address:
Contact no :
Please select your blood group ?
Blood Group
O+
O-
A+
A-
B+
B-
AB+
AB-
Name:
Submit


To access your BIM 360 Docs files with this app, you need to connect your BIM 360 account with the app.
- Log in to
BIM 360 Account Administration
. Note that you need account administrator permissions.
- If you have more than one account, select the account you want to integrate with the app.
- From the toolbar, select
SETTINGS > Apps & Integrations.
- Click the
Add Integration button.
- Select
BIM 360 Account Administration and
BIM 360 Docs, and click
Next.
- Select
I’m the developer, and click
Next.
- In the
Forge Client ID and
App Name fields, enter the Forge client ID and app name provided by the app retailer.
- Select the
I have saved the Account ID information securely checkbox.
- Click
Save.
Congratulations! You can now access your BIM 360 Docs files.


{% load hc_extras %}
You are about to log into {{ site_name }}.
Please press the button below to continue:


Get Started with sButtons
Download CSS File
You can download the CSS file
here and then add it to your
html file in between the tags.
Download the file and link it as a stylesheet in between your
tags, as shown below.
<link rel="stylesheet" href="/path/to/sbuttons.min.css">
Make sure to replace
"/path/to/sbuttons.min.css" with the path you stored it in.
CDN
Or instead of downloading the file, you can use the CDN
<link rel="stylesheet" href="https://cdn.statically.io/gh/sButtons/sbuttons/c135f5f7/dist/sbuttons.min.css">
In case of using buttons that have icons in them, make sure to include font awesome's CDN in the  tag.
<link rel="stylesheet" href="https://use.fontawesome.com/releases/v5.14.0/css/all.css" integrity="sha384-HzLeBuhoNPvSl5KYnjx0BT+WB0QEEqLprO+NBkkk5gbc67FTaL7XIGa2w1L0Xbgc" crossorigin="anonymous">
NPM
You can install sButtons using NPM:
npm i sbuttons
And then you can import the CSS file found in dist/sbuttons.css or the
LESS file found in src/sbuttons.less.
Modifying Button Colors
To modify button colors, import src/sbuttons.less in your Less file, then make changes to the variables after the import.
For example, to change the blue color to a different shade
import '/path/to/sbuttons.less';
@blue: #54a2bd; /* Make it darker */
Check out sbuttons.less for the full list of variables.
Basic Button
To use sButtons in your project, just add the classes of sButton you want to either
<button>
or
 tags
<button class="sbtn basic-btn blue-btn">Button</button>
You can find all classes and their corresponding sButtons mentioned in our Examples page.
Block Buttons
To use sButtons with block display, add the class to either <button> or
 tags
<button class="sbtn basic-btn block-btn">Button</button>
Disabled Buttons
To make a <button> or  tag
disabled, add disabled-btn class as shown below.
<button class="sbtn basic-btn blue-btn disabled-btn">Button</button>
Button
Base Icon Button
The
base-icon-btn
class enables you to have a normal, customizable button.
Using it, you decide to add any fontawesome icon in it. You can choose to either place it on the
left or right side of the button with the available classes.
Icon With No Background
The
base-icon-btn
class alone gives you a default button with no background color and a
border.
<button class="sbtn base-icon-btn"></button>
Icon Positioned to The Left
Adding the
left-icon
class to a button makes the icon positioned to the left. For example:
<button class="sbtn base-icon-btn icon-left orange-btn">To the Left</button>
Icon Positioned to The Right
Adding the
right-icon
class to a button makes the icon positioned to the right. For example:
<button class="sbtn base-icon-btn icon-right orange-btn">To The Right</button>
Toggle Button
The
toggle-btn
class along with the toggle-off-btn
/ toggle-on-btn
state class enables you to have a toggle button. Apart from the basic use, it can also be used for
checkboxes and radio buttons. While not necessary, you can use the available state classes to choose whether
your checkboxes and radio buttons are checked or not.
Toggle Button as Checkboxes
Adding the
toggle-btn
class to your checkbox inputs converts them to toggle buttons. For
example:
<input type="checkbox" class="sbtn toggle-btn"/>
Toggle Button as Radio Button
Adding the
toggle-btn
class to your radio inputs converts them to toggle buttons. For
example:
Select favourite car brand :
<input type="radio" class="sbtn toggle-btn"/>
Dark-Mode Button
The
dark-mode
class enables you to have a dark mode for a button by adding
dark-mode
class to the button
or by adding data-theme="dark"
to a container element like the div element.
Adding dark-mode as a class
Adding the
dark-mode
class :
<button class="sbtn dashed-btn orange-btn dark-mode">Dark-Mode </button>
Adding dark-mode as an attribute
Adding the
data-theme="dark"
as an attribute to a div element .It can be added to any
container element
of the button
<button class="sbtn dashed-btn orange-btn">Dark-Mode</button>


Transfer your files
fast and easily through a Pipe Connection
Room ID will show up here
Not connected
Drag & Drop to Upload File(s)
OR
image.png
(20MB)


Connect with fellow web professionals and some of the best speakers in the country for a day of presentations about leading web tech topics, plus join in hacking spaces, break-outs, and group discussions.
<title>

window.localSponsors

8:00am
Registration
Get checked in, mingle, and grab a bite to eat.
8:50am
Opening Announcements
9:00am Full Talk
The Developer's Guide to Learning Effectively
Arthur Doler
Senior Software Engineer
Aviture
10:00am Full Talk
Lee Brandt
Developer Advocate
Okta
11:00am Full Talk
The Promised Land - Painlessly Upgrading a Large Legacy Webapp
Cosmo Wolfe
Engineering Lead
Clever
12:00pm-1:20pm
Lunch Break
1:20pm-2:10pm
Lightning Talks
2:20pm Full Talk
Offline-first Web Applications
Nir Kaufman
Principal Front-end Developer
500Tech
3:20pm Full Talk
How to Dive into Deep Learning (And not get drowned trying)
Bonnie Milián
Research Developer
Universidad Galileo
4:20pm
Closing Remarks
4:30pm-5:00pm
Socializing/Networking
Breakfast and Lunch provided. Additional amenities include Hearing Loop, wheel chair accessibility, and a mother's room.
We want to make sure you have everything you need to get here and enjoy your time at 200 OK and in Tulsa.
Tulsa International Airport (TUL) is our airport if you're flying in.
Uber & Lyft are both available in Tulsa.
If you're staying in Tulsa, Aloft Tulsa Downtown, Hampton Inn & Suites Tulsa Downtown, and the iconic Tulsa Mayo Hotel are all very close to our venue.
Parking at the Central Library's garage is limited, and pricey for all day parking. There are some surrounding lots like the Cox Business Center paid lot. This will probably have more availability and is a short walk to the Library. See this online map for a couple of parking garages nearby.
We are at the Tulsa Central Library in the Pocahontas Greadington Learning and Creativity Center (Lower Level 2).
We will provide continental-style breakfast in the morning, coffee, snacks, and drinks thru-out the day, and lunch including vegan and gluten-free options.
We will give every attendee 2 tickets for drinks at one of our after-event venues: MixCo Craft Cocktails & Speakeasy Bar or All About Cha Gourmet Coffee & Tea.
If you can, you should consider sticking around Tulsa for the weekend. There are a few classic annual Tulsa events going on downtown:
Before attending the conference, please review the 200OK Code of Conduct. The CoC applies to all attendees, speakers, volunteers, and vendors at official and unofficial events by Techlahoma and any location where attendees may be congregating. Contact us if you have questions.


GopherSource is a community project created by Carolyn Van Slyck
Gopher artwork by Ashley McNamara licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 License


information/paragraph about event that can be read further by clicking the headline
One of the best plays produced is being screened at Loeb, Stewart Center on 10th November 2015! Come watch us at 6pm
A group of strangers is stranded in a boarding house during a snow storm, one of whom is a murderer. The suspects include the newly married couple who run the house, and the suspicions in their minds nearly wreck their perfect marriage. Others are a spinster with a curious background, an architect who seems better equipped to be a chef, a retired Army major, a strange little man who claims his car has overturned in a drift, and a jurist who makes life miserable for everyone.To get to the rationale of the murderer's pattern, the policeman probes the background of everyone present, and rattles a lot of skeletons. Another famous Agatha Christie switch finish!.
information/paragraph about event that can be read further by clicking the headline


Help supportive on-campus communities thrive. The 10 residential colleges provide academic assistance and activities embracing intellectual and social life.
Search or browse all giving opprtunities


No SSL
You are connecting to this site via an unsecure connection.
Do you really want to do this?
You have two choices:
You access the
encrypted page
.
You
continue
at your own risk.


Thank you for taking the time to help us improve the platform
Would you recommend freeCodeCamp to a friend?
What is your favorite feature of freeCodeCamp?
What would you like to see improved?
Additional comments


{% extends 'all-pics/base.html' %} {% block content %}
{{gallery.image_desription}}
Taken at: {{gallery.location}} taken on: {{gallery.save_date}}


#include <time_srv.h>
Public Types | |
| typedef time_srvRequest | Request |
| typedef Request | RequestType |
| typedef time_srvResponse | Response |
| typedef Response | ResponseType |
Public Attributes | |
| Request | request |
| Response | response |
Definition at line 84 of file time_srv.h.
Definition at line 87 of file time_srv.h.
Definition at line 92 of file time_srv.h.
Definition at line 88 of file time_srv.h.
Definition at line 93 of file time_srv.h.
Definition at line 89 of file time_srv.h.
Definition at line 90 of file time_srv.h.


|
UMI3D Unity SDK
2.5.b.221125
A UMI3D sdk implementation using Unity
|
Saves and manages the links between projected tools and their associated inputs. This projection is based on a tree constituted of ProjectionTreeNode. More...
Classes | |
| class | NoInputFoundException |
| Exception thrown when not associated input has been found for an interaction. More... | |
Public Member Functions | |
| AbstractUMI3DInput[] | GetInputs (AbstractController controller, AbstractInteractionDto[] interactions, bool unused=true) |
| Get Inputs of a controller for a list of interactions. More... | |
| AbstractUMI3DInput | PartialProject (AbstractController controller, ManipulationDto manip, DofGroupDto dof, bool unusedInputsOnly, ulong toolId, ulong hoveredObjectId) |
| Project a manipulation dof on a given controller and return associated input. More... | |
| AbstractUMI3DInput | PartialProject (AbstractController controller, FormDto form, ulong toolId, ulong hoveredObjectId, bool unusedInputsOnly=false) |
| Project a form dto on a controller and return associated input. More... | |
| AbstractUMI3DInput | PartialProject (AbstractController controller, LinkDto link, ulong toolId, ulong hoveredObjectId, bool unusedInputsOnly=false) |
| Project a link dto on a controller and return associated input. More... | |
| AbstractUMI3DInput | PartialProject (AbstractController controller, EventDto evt, ulong toolId, ulong hoveredObjectId, bool unusedInputsOnly=false) |
| Project an event dto on a controller and return associated input. More... | |
| AbstractUMI3DInput[] | Project (AbstractController controller, AbstractInteractionDto[] interactions, ulong toolId, ulong hoveredObjectId) |
| Project on a given controller a set of interactions and return associated inputs. More... | |
| void | SaveToFile (string path) |
| Save current state of the memory. More... | |
| void | LoadFromFile (string path) |
| Load a state of memory. More... | |
Protected Member Functions | |
| virtual void | Awake () |
Protected Attributes | |
| string | id_ = "" |
| ProjectionTreeNode | memoryRoot |
| Projection memory. More... | |
Properties | |
| string | id [get] |
Saves and manages the links between projected tools and their associated inputs. This projection is based on a tree constituted of ProjectionTreeNode.
|
protectedvirtual |
| AbstractUMI3DInput[] umi3d.cdk.interaction.ProjectionMemory.GetInputs | ( | AbstractController | controller, |
| AbstractInteractionDto[] | interactions, | ||
| bool | unused = true |
||
| ) |
Get Inputs of a controller for a list of interactions.
| controller | The controller on which the input should be |
| interactions | the array of interaction for which an input is seeked |
| unused |
| void umi3d.cdk.interaction.ProjectionMemory.LoadFromFile | ( | string | path | ) |
Load a state of memory.
| path | path to the file |
| AbstractUMI3DInput umi3d.cdk.interaction.ProjectionMemory.PartialProject | ( | AbstractController | controller, |
| EventDto | evt, | ||
| ulong | toolId, | ||
| ulong | hoveredObjectId, | ||
| bool | unusedInputsOnly = false |
||
| ) |
Project an event dto on a controller and return associated input.
| controller | Controller to project on |
| evt | Event dto to project |
| unusedInputsOnly | Project on unused inputs only |
| AbstractUMI3DInput umi3d.cdk.interaction.ProjectionMemory.PartialProject | ( | AbstractController | controller, |
| FormDto | form, | ||
| ulong | toolId, | ||
| ulong | hoveredObjectId, | ||
| bool | unusedInputsOnly = false |
||
| ) |
Project a form dto on a controller and return associated input.
| controller | Controller to project on |
| form | form dto to project |
| unusedInputsOnly | Project on unused inputs only |
| AbstractUMI3DInput umi3d.cdk.interaction.ProjectionMemory.PartialProject | ( | AbstractController | controller, |
| LinkDto | link, | ||
| ulong | toolId, | ||
| ulong | hoveredObjectId, | ||
| bool | unusedInputsOnly = false |
||
| ) |
Project a link dto on a controller and return associated input.
| controller | Controller to project on |
| link | link dto to project |
| unusedInputsOnly | Project on unused inputs only |
| AbstractUMI3DInput umi3d.cdk.interaction.ProjectionMemory.PartialProject | ( | AbstractController | controller, |
| ManipulationDto | manip, | ||
| DofGroupDto | dof, | ||
| bool | unusedInputsOnly, | ||
| ulong | toolId, | ||
| ulong | hoveredObjectId | ||
| ) |
Project a manipulation dof on a given controller and return associated input.
| controller | Controller to project on |
| manip | Manipulation to project |
| dof | Dof to project |
| unusedInputsOnly | Project on unused inputs only |
| AbstractUMI3DInput[] umi3d.cdk.interaction.ProjectionMemory.Project | ( | AbstractController | controller, |
| AbstractInteractionDto[] | interactions, | ||
| ulong | toolId, | ||
| ulong | hoveredObjectId | ||
| ) |
Project on a given controller a set of interactions and return associated inputs.
| controller | Controller to project interactions on |
| interactions | Interactions to project |
| void umi3d.cdk.interaction.ProjectionMemory.SaveToFile | ( | string | path | ) |
Save current state of the memory.
| path | path to the file |
|
protected |
|
protected |
Projection memory.
|
get |


Plugin Information |
|---|
View Wall Display Master Project on the plugin site for more information. |
The current version of this plugin may not be safe to use. Please review the following warnings before use:
A wall display that shows job build progress in a way suitable for public wall displays. Rendering is performed using javascript based on REST API calls, so requires no page refreshes.
Demo and current development snapshot
For a live demo and the latest development snapshot see http://pelle.io/jenkins-walldisplay/.
Usage
Simply click on the 'Wall Display' link in the sidebar of your project. Configuration may be done globally via the jenkins administration screen and also via URL parameters (e.g. &theme=boss)
Sample Wall Display Tips
If you have a lot of jobs, try setting filters on your view. The follow example creates a wall display that only shows interesting builds, i.e. builds with any type of failure or builds that are currently building / in the build queue.
Version History
Version 0.6.29
- Bug fix - JENKINS-26873 Sorting by Status does not work correctly
Version 0.6.28
- Bug fix - JENKINS-26745 : fix javascript error on undefined object
- New Feature - The gravatar URL can now be configured in the plugin configuration (thanks to https://github.com/timlevett)
- New Feature - The Junit result display can be switched of now
- New Feature - Jenkins display name feature is used for job name display
Version 0.6.26
- Bug fix - If there is no custom CSS theme to display it will no longer cause a JavaScript error
- Bug fix - If there is a custom CSS theme to display, it will no longer repeatedly add (jQuery 'append') the CSS to the page, it will be appended onto the page once.
Version 0.6.25
- Bug fix/UI enhancement - When there are no jobs for the filter to show, it will now print "No jobs to display" instead of an empty page
Version 0.6.24
- Bug fix - Where a job that does not have any health report information would cause a JS error and the job would not be displayed correctly.
Version 0.6.23
- Support for health icons (see http://pelle.io/health-info-icons/)
Version 0.6.22 (snapshot)
- UI Tweaks
- Custom theme CSS can be provided through the configuration screen
- New/Updated job info screen - touch a job panel to see further information, e.g. claim details, culprits, plus direct links to test results, console and build details.
- Claim Improvements - claim shown while next job building, claims don't interfere with title placement.
Version 0.6.16 (11.10.2012)
- JENKINS-14660 Plugin doesn't work when using the Nested View plugin (thanks to rodikal)
- JENKINS-15482 OOM when clicking on a view link inside a nested view
- Encoding fix
- Updated dependency to Jenkins 1.424 for JDK 7 support
- Basic sorting support
Version 0.6.13 (21.09.2012)
- JENKINS-14660 add support for Nested View plugin (thanks to rodikal)
- Restrict by last run date (thanks to gavD, see pull request for details)
- Add Gravatar display on the build wall (thanks to athieriot, see pull request for details)
Version 0.6.12 (11.07.2012)
- JENKINS-14379 Wall Display Plugin fails when hits the build with 'yellow' status
- Support for font family selection
- Added option to omit disabled builds
Version 0.6.10 (15.06.2012)
- Fix for JENKINS-12452 WallDisplay Plugin incompatible with IE8
- Make bright colour for burrent build a little darker to increase contrast to white text
- Added the HTML5 style document type
Version 0.6.9 (09.03.2012)
- Added configuration for build number display
- Added configuration for culprit
- Added Colorblind Theme
Version 0.6.8 (unknown)
- fixed job flickering
- support for job names containing spaces
- new theme with a dark background
- api read intverval as well as read timeout is now configurable via the jenkins management page
Version 0.6.7 (Dec 14, 2011)
- added build progress display for aborted jobs
- reduced data fetched via job api
- fixed broken job updates
- fixed flickering jobs
- added "boss" theme
- fixed removal of deleted builds
Version 0.6.5 (Nov 25, 2011)
- Support for nested views
- Fixed display of error messages
- Plugin now automatically reloads the page when a new plugin version is detected
Version 0.6.4 (Nov 15, 2011)
- Fixed job sorting order
Version 0.6.1 (Nov 11, 2011)
- First Html/Javascript based release
- General maven and matrix jobs support
Version 0.5.11 (Jul 13, 2011)
- plugin fails to read manually set job names when build parameters are defined
Version 0.5.10 (Jul 12, 2011)
- plugin didn't work for jobs with multiple properties showing up in the api
- marking of jobs with failed api calls (magenta colored jobs)
- paint queued markers also for running jobs
Version 0.5.9 (Jul 11, 2011)
- job names to display are no longer taken from jobs description, instead is configurable now (sorry I had to alter the behavior, but I think the new solution is much cleaner since the jobs description is there for other purposes)
- the time for computation of job progress is now taken from http response header
- job height calculation for one column displays corrected
Version 0.5.7 (Jun 06, 2011)
- plugin now also works for jobs containing spaces
Version 0.5.6 (May 20, 2011)
- fixed incorrect error with jobs that have not been executed yet
- corrected width calculation
Version 0.5.3 (Mar 17, 2011)
- fixed incorrect display with viewnames containing spaces
Attachments:
walldisplay_overview.png (image/png)
walldisplay_overview1.png (image/png)
jenkinswalldisplay.hpi (application/octet-stream)
options.png (image/png)


The three things I have learnt about myself is my mindset, they way I listen to people and the training of emotional intelligence.
After learning from the core tasks, I found that my mind can be in a fixed mindsets when it came to challenges and obstacles. Instead of embracing challenges and being fine with setbacks I would avoid both like the plague. This helped me learn that change can happen in the mindset if we are willing to persist.
I had learnt how to actively listen to others due to the looping challenges which forced actually listen to the other person without judgement or critiques. This has helped me better listen to the people I have talked to.
Emotional intelligence is something I had heard about but never tried to train and with the learning I have found how important it is to train if you want to better relate with people and for them to relate to you.
The roles of values, empathy and self-awareness is that it forces you to take a hard look at yourself and they way you treat yourself and others.  Empathy is important to not judge or feel envious about others. Everyone has their challenges and obstacles the must overcome you can either be another obstacle in their way or be someone that can help them in their challenges. Being aware of yourself is important as it help you understand yourself better. Without being self-aware you will find it hard to improve yourself as you will not put a spotlight on areas where you can improve.
What has surprised and challenge me is that you can change is you are willing. The core learning is about teaching you that you can change and improve yourself. Each lesson teaches you about looking at yourself and how training either your mind or listening skills can improve the way you learn and see the world. The challenging part is pushing myself to try it as I have been used to thinking and learning a certain way trying something new can feel daunting at times.
The importance of core learning is that the workplace is about interactions with others and learning to deal with change. You might be the best programmer but if you are unable to interact well with others then the group morale will go down and overall performance will go down. Our life is ever changing and so is the workplace and if you get stuck in your ways you might get left behind. That is why core learning is important as it gives you lessons and training that you can used to improve your interactions with others and how to deal with change.


File for reading and writing.
Use IO.fileWriter() and IO.fileReader() to create one.
NOTE: this is going to be split up in InputFile and OutputFile.
| unknown | $fd @directory |
| |
| $readByte() int @public |
Reads and returns one byte. When at end of file returns IO.eof.
|
| $readChar() int @public |
Reads one UTF-8 character.
|
| $readAll() string @public |
Reads the whole file and returns it as a string.
|
| $readAllBytes() byteString @public |
Reads the whole file and returns it as a byteString.
|
| $readAll(size) string @public |
Reads the file up to size bytes and returns it as a string.
|
| $readLine() string @public |
Reads and returns one line, excluding the terminating NL.
|
| $readLineRaw() string @public |
Reads and returns one line, including the terminating NL.
|
| $readAllLines() list<string> @public |
Reads the whole file and returns a list with all lines.
|
| $readAllLinesRaw() list<string> @public |
Reads the whole file and returns a list with all lines.
|
| $readAllLines(count) list<string> @public |
Reads the file and returns a list with up to count lines.
|
| $readAllLinesRaw(count) list<string> @public |
Reads the file and returns a list with up to count lines.
|
| $write(text) status @public |
Writes text to the file. Returns FAIL or OK.
|
| $writeByte(byte) status @public |
Writes byte byte to the file.
|
| $writeAllLines(lines) status @public |
Writes lines to the file.
|
| $flush() status @public |
Flushes buffered output. Returns FAIL or OK.
|
| $close() status @public |
Closes the file, reading/writing will no longer be possible.
Returns FAIL when flushing output failed.
|
| $Finish() status @file |
Destructor: closes the file if not closed already.
|
| |
| Inherited from IO.Writer: |
| $write(text) status @public |
Writes text converted to a string.
|
| $write(number) status @public |
Writes number as a decimal number.
|
| $write(number) status @public |
Writes number as a decimal number.
|
| $write(number) status @public |
Writes number as a decimal number.
|
| $write(flag) status @public |
Writes flag as "TRUE" or "FALSE".
|
| $write(ok) status @public |
Writes ok as "FAIL" or "OK".
|
| $write(arg) status @public |
Writes arg depending on its actual type.
Returns FAIL or OK.
|
| $writeChar(char) status @public |
Writes char as a UTF-8 byte sequence.
|
| $print(text) status @public |
Writes text and appends a newline.
Returns FAIL or OK.
|
| $print(number) status @public |
Writes number and appends a newline.
Returns FAIL or OK.
|
| $print(number) status @public |
Writes number and appends a newline.
Returns FAIL or OK.
|
| $print(number) status @public |
Writes number and appends a newline.
Returns FAIL or OK.
|
| $print(flag) status @public |
Writes flag as "TRUE" or "FALSE" and appends a newline.
Returns FAIL or OK.
|
| $print(ok) status @public |
Writes ok as "FAIL" or "OK" and appends a newline.
Returns FAIL or OK.
|
| $print(arg) status @public |
Writes arg depending on its actual type and appends a newline.
Returns FAIL or OK.
|
| $print() status @public |
Writes a newline and returns FAIL or OK.
|
| $format(fmt, arguments) status @public |
Formats the string and writes it with a newline appended.
|
| |
Known subclasses:


Royal Hospital Oman receives new medical devices
by Times News ServiceMuscat: The Royal Hospital recently received a number of medical devices for the Rehabilitation Department by a donation from Towell Group in the presence of Dr. Qasim bin Ahmed Al-Salmi, Director General of Royal Hospital and Bahja bint Ahmed Sultan, Towell Group representative, the Ministry of Health said.
A statement issued by the Ministry said: “The initiative included the provision of TheraSuit devices for children with neurological and mental disabilities and autism."
Al-Qasmi praised this initiative, which reflected the cooperation between the government and public sectors in order to promote community development under the wise leadership of His Majesty the Sultan.”
Bahja bint Ahmed Sultan, Towell Group representative, pointed out, “This initiative came to coincide with 49th National Day celebrations to reaffirm the importance of joint work between the two sectors in driving development in various fields, particularly the healthcare field.”


Home
About
Products
Blog
Contact
Contact Us
First Name:
Last Name:
Male:
Female:
Other:
Email:
Submit


Metages Worku
Contact
(current)
Portfolio
About
Portfolio
Click ScreenShoot images to see recent projects
Weather-Dashboard
Day planner
Password-Generator
Project1-!Bored
Code-Quiz
Eat-Da-Burger
Project2-DigitalElf


Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This Note refines the objectives for the Web Security Context Working Group deliverables. It elaborates upon the group's Charter [WSC-CHARTER] to explain what the group aims to achieve, what technologies may be used and how technical proposals will be evaluated. This elaboration is limited to the group's technical work and does not cover additional activities the group intends to engage in, such as ongoing outreach and education.
This Note also includes an initial collection of use cases that the group expects will drive its technical work.
Since this Note discusses the assumptions, goals, and processes the group will use to develop its recommendations, the intended audience is similiar to that of the charter of the Working Group; group members, the W3C community, developers of web user agents, web content providers (server administrators), and parties interested and engaged in what the Web Security Context Working Group's plans and directions are. It is explicitly not targeted at the presumed beneficiaries of the group's work, the users of the web, and it is not expected that an average user would be able to read this document and understand it.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is the W3C Working Group Note "Web Security Experience, Indicators and Trust: Scope and Use Cases". The W3C Membership and other interested parties are invited to send comments to<EMAIL_ADDRESS>(with public archive).
This document was produced by the Web Security Context Working Group, as part of the Security Activity. Several Working Drafts for this Note were available for review; the material in this document was subject to a public last call. At the time of publication, the Working Group has no specific plans to further revise this document.
Publication as a Working Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
1 Overview
2 Goals
2.1 Document the
status quo
2.2 Relevance of
security information
2.3 Consistent
presentation of security information
2.4 User awareness
of security information
2.5 Reliable
presentation of security information
2.6 Reduce the number of scenarios in
which users need to make trust decisions
2.7 Authoring and
deployment techniques
2.8 Best
practices for other media
3 Non-goals
3.1 Presentation of all security
information
3.2 Non-HTTP Web
interactions
4 In scope
4.1 Web
interactions
4.2 User
agents
4.3 Entity
identification
4.4 Third-party recommendation
4.5 Historical browsing information
5 Out of scope
5.1 Protocols
5.2 non-Web interactions
5.3 Security
context information for consumption by automated
agents
5.4 New security
information
5.5 Content based
detection
5.6 Security information about the user's
computer
5.7 User agent
exploits
5.8 User
separation
5.9 Content production
exploits
5.10 Other security challenges
6 Use cases
6.1 User
decisions
6.1.1 Providing sensitive information to a web
site
6.1.2 Believing information to come from a known
author
6.1.3 Installing software downloaded from a web
site
6.2 Navigation
6.2.1 Unidentified destination
6.2.2 Unidentified source
6.3 User
agent type
6.3.1 Desktop browser
6.3.2 Smartphone
6.4 Accessibility
6.5 Scenarios
6.6 Threats
6.6.1 Subverted navigation
<IP_ADDRESS>
URL typo
<IP_ADDRESS>
Misleading bookmark
<IP_ADDRESS>
Misleading
introduction
<IP_ADDRESS>
Unprotected
navigation
6.6.2 Web site impersonation
7 Security information available to the
user agent
7.1 Defined by web content
specifications
7.2 Defined by
SSL related specifications
7.3 Defined by
HTTP related specifications
7.4 Defined by IP
related specifications
7.5 Defined by
DNS related specifications
7.6 Defined by
user agent
7.7 State that may be collected by a user
agent
7.8 Defined by a third-party
8 Merits of the status quo
8.1 Widely
deployed, strong cryptography
8.2 Many
deceptive imitation techniques prevented
8.3 Corrected
implementation errors
8.4 Password management
9 Problems with the status quo
9.1 Poorly
defined area for chrome
9.1.1 Picture in picture
9.1.2 Visually extending the chrome
9.1.3 Removing the chrome
9.2 Poorly
defined role for chrome
9.2.1 Browser window title
9.2.2 Back and forward buttons
9.2.3 URL bar
9.2.4 Padlock icon
9.2.5 Favicon
9.2.6 Status bar
9.2.7 Information bar (aka: notification
bar)
9.3 Poor user
understanding of chrome
9.3.1 Padlock icon
9.3.2 Hostname
9.3.3 Chrome versus page
9.3.4 Explanations versus
understanding
9.4 Poor
usability of chrome
9.4.1 Out of sight, out of mind
9.4.2 Assumed safety
9.4.3 Poor usability of dialog boxes
10 Process
10.1 Expertise and
experience
10.2 Reliance on general usability
expertise
10.2.1 Affordance
10.2.2 Conceptual model
10.2.3 Match between system and the real
world
10.2.4 Habit formation
10.2.5 Single locus of attention
10.2.6 Aesthetic and minimalist design
10.2.7 Help users recognize, diagnose, and recover
from errors
10.2.8 Provide explanations, justifying the advice or
information given
10.2.9 Understand the user
10.2.10
Create task profiles
10.2.11
Consistency
10.3 Learning from past efforts
10.3.1 No user categories in phishing
vulnerability
10.3.2 The user must be aware of the task they are to
perform
10.4 Implementation and testing
11 Acknowledgments
12 References
Web user agents are now used to engage in a great variety and number of commercial and personal activities. Though the medium for these activities has changed, the potential for fraud has not. This Working Group is chartered to recommend user interfaces that help users make trust decisions on the Web.
This first Working Group document elaborates upon the group's Charter [WSC-CHARTER] to explain what the group aims to achieve, what technologies may be used and how proposals will be evaluated. This elaboration is limited to the group's technical work and does not cover additional activities the group intends to engage in, such as ongoing outreach and education.
The work outlined in this document is expected to take existing standards and best practices into account. Where relevant, such existing work will be leveraged.
Security information within the Working Group's scope will be catalogued, along with corresponding presentations and user interpretations reported in user studies.
The Working Group will analyze common use cases to determine what security information the user needs to safely accomplish their current task and recommend security information that should, or should not, be presented in each case.
The Working Group will recommend a set of terms, indicators and metaphors for consistent presentation of security information to users, across all web user agents. For each of these items, the Working Group will describe the intended user interpretation, as well as safe actions the user may respond with in common use cases.
The Working Group will recommend presentation techniques that integrate the consumption of security information by the user into the normal browsing workflow. Presenting security information in a way that is typically ignored by the user is of little value.
The Working Group will recommend presentation techniques that mitigate deceptive imitation, or hiding, of the user agent's presentation of security information.
No matter how well security context information is presented, there will always be users who, in some situations, will behave insecurely even in the face of harsh warnings. Thus, the Working Group will also recommend ways to reduce the number of situations in which users need to make trust decisions.
The Working Group will recommend authoring and deployment techniques that cause appropriate security information (see 7 Security information available to the user agent) to be communicated to users. Techniques already available at authoring and deployment time which reduce the need for communication of security information to the user will be considered in the recommendations.
Users' interpretation of security information on the web will necessarily be affected by experience with other media that are not part of this Working Group's scope; such as email, print, radio or video. The Working Group will provide best practice guidelines for other media to follow so as not to undermine the presentation of security information on the web.
This section outlines a range of work items which the group will not focus on, but which may be covered as beneficial side effects of the group's work. Work items listed here won't be a priority, and the group won't expend collective resources on tackling them.
Web user agents contain a great deal of information relevant to security. This Working Group does not aim to recommend a presentation for all of this information. Recommendations will be narrowly focused on presentations that satisfy the Working Group's use cases, see 6 Use cases.
Recommendations that this group makes may or may not be relevant to Web related interactions that use protocols other than HTTP or HTTPS. While the group will aim for its recommendations to be generically useful -- where appropriate --, it considers recommendations specific to other protocols as a Non-Goal.
This section enumerates categories of technology and information that are within this Working Group's scope, as initially defined by the group's Charter [WSC-CHARTER]. A complete enumeration of in scope artifacts is provided by the section 7 Security information available to the user agent.
User interactions on the Web (see Architecture of the World Wide Web [WEBARCH]), using the HTTP and HTTPS protocols, are at the core of the Working Group's scope. Where Web interactions involve other application-level protocols (including, e.g., SOAP or FTP), the Working Group considers these in its scope and will aim that its recommendations be applicable; however, applicability to non-HTTP Web interactions (see 3.2 Non-HTTP Web interactions) is a non-goal.
A user agent is software to access Web content, including desktop graphical browsers, text browsers, voice browsers, mobile phones, multimedia players, plug-ins, and some software assistive technologies used in conjunction with browsers such as screen readers, screen magnifiers, and voice recognition software. This definition is in line with Web Content Accessibility Guidelines 1.0 [WCAG].
Use cases considered by this Working Group must involve a web user agent, operated by a human user. In all instances, the use case is only relevant to this Working Group if the presentation of security information should affect the user's interaction with the web resource.
A web browsing session is like a conversation, where the user converses with various entities, some known, and others newly encountered. Each resource the user interacts with is identified by a URI. Through specifics of the underlying protocol, including DNS and SSL, other designators are bound to these resources and the entities that provide them. Recommending a presentation for these designators that helps the user recognize which entity they are currently conversing with, and when they are switching to a different entity, is a primary concern of this Working Group.
A user's perception of an entity is strongly influenced by the opinions of others. The recommendations of certificate authorities, visited web sites or reputation services integrated into the user agent are in scope for this Working Group.
The Working Group may also use information about past interactions between the user and an entity in presentation recommendations. Relevant historical browsing information includes entity designators used in past browsing sessions, as well as information provided by the user to the entity during those sessions.
This section enumerates a number of possible work items that the Working Group will not consider.
The Working Group considers recommendations for lower level protocols (such as SS7, ISDN, or NANP) out of scope.
The Working Group considers recommendations specific to interactions that do not involve the Web (e.g., rich text display in an e-mail user agent) out of its scope. However, where such interactions use Web Technologies, recommendations may turn out to be applicable.
The Working Group will only consider Web interactions in which a human participates in making a trust decision this group is chartered to address.
The Working Group will neither create nor extend any protocol or data format, nor create recommendations for protocols or data formats that are not yet widely deployed. Recommendations will only be made for the presentation of currently deployed security information.
Techniques commonly used by intrusion detection systems, virus scanners and spam filters to detect illegitimate requests based on their content are out of scope for this Working Group. These techniques include recognizing known attacks by analyzing the served URLs, graphics or markup. The heuristics used in these tools are a moving target and so not a suitable subject for standardization. The Working Group will not recommend any checks on the content served by web sites.
Security information about the user's computer, such as that provided by virus scanners, or trusted computing infrastructure, is out of scope for this Working Group. No recommendations will rely on such services, or any aspect of trusted computing. As a result, presentation techniques recommended by this Working Group may be undermined by malware that has infected the user's computer.
Attacks that exploit a programming error in the user agent are out of scope. This Working Group's recommendations assume a properly functioning user agent.
Many computers are shared among multiple users, either in the home, or as a kiosk in a public place. In such scenarios, the activity of one user must not be accessible to another. Providing this functionality may be best done by the operating system, or other software, and is out of scope for this Working Group.
Programs that produce HTML, or other web content, commonly suffer from quoting errors that enable Cross-site scripting (XSS) attacks. The web user agent is in a poor position to detect these attacks, since it sees only the output. Web content formats are not currently designed such that the receiver can readily distinguish content that was produced on purpose versus content that was produced by accident. Consequently, this kind of attack is out of scope for this Working Group.
As stated in the charter, the mission of the Web Security Context Working Group is to specify a baseline set of security context information that should be accessible to Web users, and practices for the secure and usable presentation of this information, to enable users to come to a better understanding of the context that they are operating in when making trust decisions on the Web. While the work this group does may have a positive and beneficial effect on other security challenges on the web, directly addressing such challenges is out of scope. This section lists several specific challenges, but the list may not be exhaustive.
This Working Group is concerned with: the trust decisions users must make when using the Web; what information may inform these decisions; and usable ways of communicating needed information to the user. Our use-cases are first structured by the kind of decision facing the user, where each kind of decision brings different risks. The information available to inform a decision is primarily determined by how the user navigated to the web page where the decision arose. Our use-cases are further categorized by the different means of navigating the Web. Finally, the feasible user interactions for communicating relevant information are limited by the I/O features of the web user agent. Our use-cases are finally tailored to the kind of web user agent.
Many activities on the Web, such as logging into an account or completing a purchase, require providing sensitive information to a web site. If the user is interacting with the intended site, and they are not reassured of this case, they may not complete a desired transaction. If the site is not the intended one, and the user is not warned of this case, a thief may receive sensitive information.
The Web is most often used for viewing information produced by others. Sometimes, the user may form an opinion, or make a decision, based on this information. This act may be greatly influenced by who the user believes to be the information's author. If the user is misled about authorship, a thief may convince the user to take an unwarranted action. If the user is unsure about authorship, they may not act on needed advice.
Not all content available on the Web remains confined to the web browser. Some content can be installed as an executable application on the user's computer, or as an extension to an existing application, or extend the web browser itself. On today's popular operating systems, an installed application has much greater access to the user's computer than does a web page. An application may abuse this additional authority by stealing the user's files, rendering the computer unusable, or using it to attack yet other computers. Choosing to not install an application may also be detrimental, as a needed security patch is not applied, or desired functionality is not acquired.
A hyperlink is navigated from a source to a destination. Information about each may be relevant to a trust decision the user makes on the destination web page, but this information is not always available. Even when available, this information may not be meaningful to the user. The identification provided by either source or destination may not correspond to any entity known to the user. A source or destination is considered identified when the presented information can be attributed to an authenticated entity, such as via an SSL server certificate.
Information about the destination of a hyperlink may be unavailable because:
the web page does not support authentication, such as provided by SSL
(In the absence of SSL, communication with the destination host may be intercepted by a compromised DNS lookup, or an illegitimate wifi access point.)
the provided authentication certificate is unrecognized, or expired
In addition to the ways destination information may be unavailable, source information may be unavailable because:
navigation was initiated from another application, such as an email or chat client
the user typed in the destination URL
the source web page makes no warranty as to the purpose of the hyperlink, such as is common for a search engine or open discussion forum
The use-cases address two different kinds of user agent, each distinguished by characteristic I/O features.
A desktop browser typically has:
a large, full color viewing area
a pointing device
a full-size keyboard
speakers
The user agent in a mobile browser typically differs from its desktop counterpart in several ways:
Screen: a small, limited color viewing area
Navigation input: small keyboard, stylus or pointing device
Small keyboard pad: on-screen keyboard and predictive text technology, such as T9
Tactile feedback: vibration
A/V interfaces
Traffic cost awareness, slow connection speed and trust in the mobile network infrastructure may also affect how users interact with their smartphone's user agent. These factors influence how security indicators are presented by different smartphone user agents.
In mobile browsers, the chrome has fewer options and overlaps with the phone's menus. Obtaining secondary information is cumbersome, requiring several clicks. Due to a lack of screen space, the padlock is shown but the URL is only partially shown, if at all. Password management is not supported in all phones. In some cases, an accessed web page has a modified look and feel, different from simply viewing the page on a small screen. These changes may create suspicion among security-aware users. User agents rarely check for certificate revocation, since doing so generates network traffic. Some certificate authorities commonly found in desktop browsers are not included in smartphone user agents. Consequently, the user may be presented with warnings that do not appear when the same site is visited using a desktop user agent. Large pages that do not fit in the phone's RAM can cause unexpected behavior in the user agent's security indicators.
The use cases in this document make no particular assumptions about the capabilities and cultural background of the user in question. [WCAG]
They may not be able to see, hear, move, or may not be able to process some types of information easily or at all.
They may have difficulty reading or comprehending text.
They may not have or be able to use a keyboard or mouse.
They may have a text-only screen, a small screen, or a slow Internet connection.
They may not speak or understand fluently the language in which the document is written.
They may be in a situation where their eyes, ears, or hands are busy or interfered with (e.g., driving to work, working in a loud environment, etc.)
They may have an early version of a browser, a different browser entirely, a voice browser, or a different operating system.
In the table below, each cell contains links to use-cases that fall into the category determined by the cell's placement in the table. The hypertext of each link names the type of user-agent being used; where "any" means the use-case is not specific to a type of user agent.
| Providing | Believing | Installing | |
|---|---|---|---|
| Identified source, Identified destination | case1, case2 | case8, case9 | case15 |
| Identified source, Unidentified destination | case3 | case10 | case16, case17 |
| Unidentified source, Identified destination | case4, case5, case6 | case18, case19 | |
| Unidentified source, Unidentified destination | case7 | case11, case12, case13, case14 | case20 |
Identified source, Identified destination, Providing
Once a week, Alice pays her bills. She opens her web browser, follows the habitual bookmark to her bank's site, logs in by entering her credentials, and follows the routine course through the online banking system.
Identified source, Identified destination, Providing
Betty's home wireless router has a web interface for making configuration changes. When the router is installed, it generates a self-signed SSL server certificate. Sometime later, Betty attempts to make a configuration change. How does Betty know she's connected to the router she setup earlier, and not her neighbor's?
Identified source, Unidentified destination, Providing
Once a week, Alice pays her bills. She opens her web browser, follows the habitual bookmark to her bank's site, and is directed to an unfamiliar site at a new domain, announcing that her bank has recently acquired another one and changed names a bit. She is asked to enter her usual credentials, succeeds, and quickly adapts to the new online banking system.
Unidentified source, Identified destination, Providing
In the advertising leading up to a re-run of the 1970s movie classic "The Sting," Doyle sees an offer for a new-fashioned investment that he can't refuse, offered by a brand that he has heard of before. He memorizes the URL that is given toward the end of the advertising. Coming back home, he mis-types the URI at first, corrects a spelling error, and then reaches a web site that matches the investment firm's branding and name. He's asked for identifying information that he provides.
Unidentified source, Identified destination, Providing
Example Inc. has use of example.com, example.net and example.org. Each is used to manage a different part of the company's online operations. Betty initially found Example at example.com and created her online account through a page hosted at that domain. She has yet to interact with any of Example's other hosts. Sometime later, Betty receives an email claiming to be from Example and alerting her to a pending task that she must attend to. The email provides a hyperlink to a page that will help Betty complete the task. After clicking on the hyperlink, Betty's user agent displays a page from the example.net host. The page asks Betty to enter her username and passphrase before being allowed to access her account. How is Betty to know that her Example credentials can be safely entered into the page?
Unidentified source, Identified destination, Providing, smartphone
While on the move, Alice suddenly remembers she has to make an urgent banking transaction. She has used her mobile browser previously for retrieving information from the web, but this time she decides to use her phone due to the urgency. She starts her mobile phone browser and enters a URL that she recalls having seen on her home desktop browser. After some delay, longer than usual, the phone starts showing a page. Due to screen size, Alice notices that the layout is somewhat familiar, but still not the same as the one in her dekstop. She can't see the full URL either. Alice scrolls and spots the link that takes her to the transaction page and clicks on it. After some delay, the phone displays a page asking her to enter her usual bank credentials. How is Alice to know that her bank credentials can be safely entered into the page?
Unidentified source, Unidentified destination, Providing
Example Inc. has a popular online service that processes many credit card transactions a day. Betty occasionally uses the service and trusts it with her credit card information. Malcolm is a thief with an idea. He creates an imitation of the Example web site and begins directing users to it. Malcolm contacts victims through email, or even the phone, and links to his imposter site from popular blogs and chat forums. He's also given his imposter site a domain name that is just a typo away from Example's authentic web site, so some victims will arrive by accident. Betty is about to enter her credit card information into a site that looks just like Example's. How is she to know if it's the authentic site, or the imposter?
Identified source, Identified destination, Believing
Betty occasionally visits the example.com web site. On each connection, Betty's user agent receives an SSL server certificate issued by the same certificate authority. On the current connection, the received certificate was issued by a different certificate authority. What should the user agent display? Can Example Inc. affect this display through the content of the new certificate?
Identified source, Identified destination, Believing
Betty clicks on a hyperlink to the web page at
<https://www.example.com/>
. The
received HTML page includes content received from
<https://www.example.net/>
. Betty's
user agent is unaware of any relationship between the
www.example.com and www.example.net web sites.
Identified source, Unidentified destination, Believing
Betty visits the web page at
<https://www.example.com/>
. The
received HTML page includes content received from
<http://www.example.com/>
, i.e.,
content received using a different security
context.
Unidentified source, Unidentified destination, Believing
Betty tries to connect to a web site at
<https://www.example.com/>
. Her user
agent's SSL implementation detects that the domain name
specified in the certificate differs from
www.example.com. What should the user agent
display?
Unidentified source, Unidentified destination, Believing
Betty is planning a trip to a foreign country. Searching the web, she finds a widely recommended local travel agency. When she connects to their web site, her user agent does not recognize the certificate authority that issued the travel agency's SSL server certificate. What should the user agent display?
Unidentified source, Unidentified destination, Believing
Like many users, Betty has grown accustomed to quickly clicking through any warning dialogs presented by her user agent. Out of habit, Betty dismisses another one, then quickly becomes suspicious about some of the web page's content.
Unidentified source, Unidentified destination, Believing
Betty has travelled to a foreign country. In a coffee shop, she is reading a political web site from her home country. She wonders whether the information that is displayed to her is authentic, and whether there will be eavesdropping on her interactions.
Identified source, Identified destination, Installing
Once a week, Alice pays her bills. She opens her web browser, follows the habitual bookmark to her bank's site. Her bank's web site informs her that, as a countermeasure to recent attacks against online banking customers, she needs to install a piece of proprietary software on her computer that will be the conduit for her future interactions with the bank.
Identified source, Unidentified destination, Installing
Frank regularly reads a frequent flyer forum while sipping his first cup of coffee in the morning. He clicks on a link and walks off to the coffee-maker for a refill. Returning, he notes that his computer screen now includes pop-up advertising for a new cheque-management program which is purportedly offered by his bank. A free demonstration version is available for download. The advertising is served from an advertising agency's web site, not from the bank's.
Identified source, Unidentified destination, Installing
Vicki is interested in finding out more about art auctions in the greater Boston area. She engages a search engine and tries to follow a link there. Her web browser consults a reputation service which has recorded that the link target will attempt to subvert the browser and install malicious software.
Unidentified source, Identified destination, Installing
Watching more cinema advertising, Doyle sees a somewhat irritating, but intriguing movie teaser that ends with a dark screen that has a URL fading away quickly. He mis-memorizes the URL. Coming back home, he types in what he remembers, and gets directed to a web site that immediately causes a software download. A pop-up window informs him (in graphical layout that matches the teaser's last screen) that software will be installed on his system in order to enable him to fully benefit from the web site's multimedial offerings.
Unidentified source, Identified destination, Installing
Steve runs a suite of security software on his machine that regularly upgrades certain components. The typical workflow is that a specific browser window is opened automatically. Steve will then control the selection of software upgrades, will download them from the web, and they will then be installed.
Unidentified source, Unidentified destination, Installing
Once a week, Alice pays her bills. She opens her web browser, follows the habitual bookmark to her bank's site. A download process starts, and a pop-up window informs Alice that she needs to install a piece of software locally that will henceforth be her conduit for her future online interactions with her bank.
Identified source, Identified destination, No interaction
Betty tries to connect to a web site at
<http://www.example.com/>
. She
visits this site frequently to read various news and
articles. Since her last visit, the site example.com
has been compromised by some method, and visitors are
now being infected with malware. At the time of the
current request, Betty's user agent now has information
saying that example.com is a known bad site. What
interaction, if any, should occur?
Unidentified source, Unidentified destination, No interaction
Frank regularly reads his email in the morning. This morning he receives an email that purports to be from his bank and asks him to verify a recent transaction by clicking on the link embedded in the email. The link does not display the usual URL that he types to get to his bank's website, but it does have his bank's name in it. He clicks on the link and is directed to a phishing site. The phishing site has been shut down as a known fraudulent site, so when Frank clicks on the link he receives the generic Error 404: File Not Found page. Frank is not sure what has occurred.
The scenarios provided above are vulnerable to a wide range of threats. Threats which are in scope for this Working Group are further discussed in 4 In scope. Section 5 Out of scope covers threats which, though dangerous and important, will not be directly addressed by this Working Group. A comprehensive threat tree, for both in scope and out of scope threats, is work in progress; see Web User Interaction: Threat Trees [WSC-THREATS].
When following a hyperlink, the user may have an expectation, based on how they found the hyperlink, for what the destination page should be. These expectations will be misplaced if an attacker can replace the expected hyperlink with one that leads to a different destination page.
In scenarios where the user types a URL into their browser, there is a risk of mistyping. An attacker can acquire the rights to common typo variants of a hostname and so cause the navigation to lead to an attack page, instead of the expected page.
In scenarios where the user navigates to a page via a bookmark, there is a risk of selecting the wrong bookmark. Browsers commonly identify bookmarks by the corresponding page title, the value of which is chosen by the page author. If an attacker can convince the user to bookmark a page, using another pretense, the user will have a bookmark identified by a name of the attacker's choosing and leading to a page of the attacker's choosing.
Discussion forums and search engines serve content produced by others, or derived from content produced by others. A user may apply the trust they have for these sites to the hyperlinks they serve. Most often, this trust is well placed, since the sites aim to serve useful hyperlinks. An attacker, posing as a normal site contributor, may cause the site to serve a hyperlink to an attack page. In this case, a user may follow the hyperlink, and apply their trust for the site to the attacker's page.
Most of the URLs currently in use do not use SSL, or similar protection. An attacker with access to the network layer can replace a requested URL with one of their own choosing. Consequently, even a hyperlink that refers to the expected destination page can be made to refer to a page of the attacker's choosing.
If an attacker is unable to subvert the navigation step, it still may be possible to convince the user that the attack page is the expected page. Techniques for doing this are described in 9 Problems with the status quo. That section discusses deficiencies in the browser user interface.
This section provides an enumeration of the security information this Working Group has determined to be in scope and so available for use in recommendations. The Working Group's scope is detailed in sections 4 In scope and 5 Out of scope. Information is grouped into sub-sections according to the references that should be consulted to determine its semantics.
MIME type
The reported MIME type, along with other information the user agent may collect, such as filename extension, affect what user agent features are triggered by the receipt of web content.
target URI
The target URI for an HTTP request is constructed according to the instructions provided by the web content from which the request was produced. The target URI determines the recipient of the request.
presence of client-side dynamic content
The rendering of a web page composed of only static content has a completion point, after which the rendered view remains constant until the user chooses to navigate to another web page. Dynamic content is anything that changes this interaction or is given additional access to user agent functions. Java and Javascript are two current examples, as is an HTML META tag specifying a page refresh.
Is the rendered view composed from multiple resources, such as referenced images or stylesheets?
The message communicated by a web page may be significantly affected by partial rendering. The web content specifies what resources the web page's author considered part of the rendered view.
Is the rendered view composed from resources from distinct hosts?
When a web page includes by reference a resource from another host, the rendered view may be significantly different than the page author expected. For example, the HTML IMG tag can lead to such surprises.
SSL server certificate chain [PKIX]
certificate authority
distinguished name
public key
validity timeframe
extended validation [EV Cert]
Ciphersuite
public key algorithm and key length
symmetric key algorithm and key length
message digest algorithm
revocation status
Both CRLs [PKIX] and OCSP [OCSP] provide information about the revocation status of a certificate.
HTTP redirect [HTTP]
HTTP-Auth handshake [HTTP Auth]
cookie handling [HTTP Cookie]
Must requests be transmitted using SSL? [HTTPS]
server IP address
localhost versus intranet versus internet
network diagnostic information, such as provided by ping or traceroute
server hostname
DNSSEC protection of hostname lookup [DNSSEC]
installed certificate authorities
installed search engines
default window layout
default bookmarks
default configuration
Has rendering of a page completed?
referring page
SSL session [TLS], if any, that protected content transmission
submitted passwords
submitted form values
bookmarks
browsing history
installed client certificates
installed server certificates
How was the URL entered?
typed into address bar
pasted into address bar
clicked hyperlink
command from another application
user agent customization
user response to prompts
reputation service
other visited web pages that link to the current page
search engine results
Successive generations of web user agents have improved upon past implementations and achieved greater deployment of security relevant infrastructure. This work provides a base upon which this Working Group will build its recommendations. This section calls out the aspects of the currently deployed web infrastructure that have already narrowed the problem space we need to address, or that we intend to learn from or build on.
Since its first deployment, the SSL protocol has undergone multiple revisions, culminating in the current TLS/1.1 protocol. Both client and server implementations are widely deployed, enabling applications to communicate in a way that is designed to prevent eavesdropping, tampering, and message forgery.
The most current generation of desktop web browsers contain several changes aimed at protecting users from the types of spoofing attacks seen in the past. Some of these changes are invisible to users, such as preventing a web site from opening a window which is larger than the visible desktop. Other changes are more noticeable, such as warning dialogs which alert users when they arrive at a website that matches an entry on a list of suspected phishing sites.
Recent web browsers correct many of the security relevant implementation errors in past browsers. Many errors in the implementation and application of the SSL protocol are now corrected.
Modern browsers include a password manager that can autofill the corresponding user login credentials for a web site. This feature provides several usability benefits that can help users notice and avoid web based attempts to steal their passwords. Autofilling provides a presentation cue indicating the credentials have been previously submitted to the web site. The user may then infer that the current operation is simply a repeat of a past trust decision, rather than a new trust decision: the decision to give the web site the corresponding password has already been made. A password manager can also eliminate the step of typing a password into a web page, a step highly vulnerable to phishing.
Though much implementation progress has been made, there remain problems with the basic design for communicating security information to the user, which is the core of the mission of this Working Group. In current user agents, security information is primarily presented through modal dialog boxes and indicators in the browser's chrome. Chrome is the representation through which the user interacts with the user agent itself, as distinct from the web content accessed. In graphical layout terms, chrome is the part of the user agent window outside of the area displaying the current web page. This user interface has a number of inherent problems, as well as problems created by the current realization.
The above definition of chrome reveals a major shortcoming in the concept. Chrome is primarily defined by where it is not, rather than where it is. As a result, there are a number of tricks for confusing the user about which parts of their screen contain browser chrome.
Modern desktop operating systems support overlapping windows of varying sizes. A smaller browser window overlaying a larger browser window can be visually indistinguishable from a larger browser window displaying a picture of a smaller browser window in the web page area. Using dynamic content technology, this picture of a window can be given functionality that closely mimicks that of a real browser window. In this case, the user may treat the web page content as a real browser window and believe the imitation chrome is real chrome.
This level of visual deception may be unnecessary to fool many users. Studies have demonstrated that many users still do not fully grasp the flexibility of the desktop metaphor and wrongly believe the security indicators of one browser window also pertain to another located on top of, or next to it. [Why Phishing Works]
The strongest visual cue the user is given for the boundary between the chrome area and the web page area is a change in background color. The chrome uses the background color for application menus, typically a light grey, and the web page area uses whatever background color it wishes, but typically white. There is nothing preventing the web page from using the same background color as the chrome area for part of the web page area near the chrome. In this case, the chrome area may appear to be extended with additional security indicators specified by the web page. In addition, color only cues often do not work for users who are color blind.
Curiously, recent releases of prominent browsers now use a similar technique to present security information to the user from the web page area. Typically the chrome extension uses a light yellow background and appears near the top of the web page area. A web page could provide an identical presentation with a message like: "This web page is guaranteed by Example Inc. to be safe for e-commerce."; where the name Example Inc. would instead be a brand name widely trusted by users. Since users have been conditioned by the browser to expect relevant security information to be presented in this way, they may trust the message.
Employing the above visual tricks may be unnecessary for a successful attack, since the browser may support removing the chrome from a browser window, at the discretion of the visited web site. In this event, the vacated area of the browser window becomes additional web page area. Simply depriving the user of the chrome's security indicators may be sufficient, or the attacker could display imitation chrome in the same area the user expects to find real chrome.
Replacing the real chrome with imitation chrome may be unnecessary for a successful attack, since currently all of the indicators in the chrome display information chosen by the attacker. By choosing values for these indicators which are likely to deceive the user, the attacker can produce an imitation of the victim web site using the real chrome, rather than imitation chrome. It is unclear in what way the user should rely on the chrome, when the chrome displays only information chosen by the attacker. Following is an exhaustive list of the indicators found in the chrome of common web browsers, and the corresponding source of the displayed information.
The browser's window title is constructed using the
content of the HTML TITLE
element from the
displayed web page. The attacker has full control over
the content of the displayed web page.
In a browser with multiple tabs for viewing multiple
web pages, the tab title also uses the content of the
TITLE
element.
Both the back and forward navigation buttons provide a
drop down list of previously viewed pages. Each page is
identified by the content of the corresponding HTML
TITLE
element.
The current web page's URL is chosen in tandem by the creator of the referring hyperlink and the web site operator. When an attacker is directing victims to an imposter web site, the attacker is both the creator of the referring hyperlink and the web site operator.
Some browsers provide an additional display of the hostname of the visited web site. The displayed hostname is taken from the current web page's URL. An attacker can choose any hostname that is not already in use, including ones that may deceive users. See section 9.3.2 Hostname for additional discussion.
The padlock icon indicates the use of SSL. The decision to use SSL, or not, is again at the discretion of the creator of the referring hyperlink and the web site operator. In a phishing scenario, the attacker still plays both these roles. When the web site operator is an independent party it may redirect a URL chosen by the attacker to an SSL protected URL; however, this redirect is delivered over the original unprotected connection.
Websites can specify a small graphic to act as an icon that appears in the URL bar in most desktop web browsers and on the tabs in some browsers [Favicon]. While the desktop web browsers control this chrome, none place any restrictions on the type of websites or the content of the images that will be displayed. Consequently, an imposter web site can display the icon of an impersonated web site in the web browser's chrome.
A website may also choose to display a favicon that looks exactly like the padlock icon that is displayed in the URL bar by many browsers to indicate an SSL connection. In this case, the user may believe that SSL is being used, when it is not.
By default, the status bar displays messages from the browser, such as the target of the hyperlink under the mouse cursor. The displayed web page can also display any message of its choosing in this area.
Some desktop web browsers use a colored bar called an information bar (or notification bar) across the top of the web content window to communicate with users. These messages are specific to the content of the web content window, and usually alert the user to the fact that a potentially undesirable action has been suspended, such as the automatic installation of software or the opening of a new web content window.
While the content of the information bar is controlled by the web browser, a convincing replica of this interface can easily be created by a malicious web site and placed at the top of their content.
Employing a great deal of deception might also be unnecessary for a successful attack, since studies have shown many users have a poor understanding of the chrome. The current chrome indicators provide a thin summary of raw technical artifacts drawn from the network protocol's current exchange. The full meaning of these protocol artifacts is not necessarily understood by users.
The presence of the padlock icon in the chrome only indicates the current web page was transmitted using the SSL protocol. The icon does not denote a guarantee of trustworthiness, nor is it an indication of legitimacy; an imposter site can be accessed using the SSL protocol. On its own, the fact that SSL was used is not actionable. The fact must first be paired with many others before a warranted decision can be made. Nevertheless, some studies have shown the presence of a padlock icon, when it is noticed, contributes to a user's vague sense of security [Users' conceptions]. Relying on the padlock icon in this way is not supported by the mere use of SSL by a web page.
DNS is a hierarchical name space. Name assignments on upper layers of this name space are controlled by various policy and business processes and often thought of as identifiers for real-world entities; name assignments on the lower layers are typically choosen freely and often thought of as identifiers for individual hosts or services. However, these intricacies are not widely understood. Studies show that users will interpret brand names that occur on any level of a domain name as a signal that allows them to assume some kind of reliable association between the brand and the domain name [Security Toolbars].
Perhaps the most surprising result of user studies is that the distinction between chrome and page area does not exist in the minds of many users. Professional looking content is deemed a more reliable indicator of legitimacy. A padlock icon appearing in the page area has the same significance as one in the chrome [Security Toolbars]. Whether an indicator in the chrome is a security indicator, or a decoration set by the web page is unclear [Why Phishing Works]. Given the reality of the current functionality of the chrome, these user perceptions are quite reasonable. Current chrome is just a decoration whose content is largely, or entirely, determined by the visited web site.
Users come to an understanding of security indicators predominantly through use and direct experience, and somewhat through general awareness (discussions with others, news and other information they might receive). Users knowing about the padlock icon at all, for example, shows that user education does happen over time. Experience and history with education on using computer software indicates that users do not learn and act exactly on what is explicitly taught them (for an example of that in user security, see [Make Up Your Mind]). Explicit user education does not override other problems and does not consistently alter user behavior.
Even if the chrome was perfectly implemented and fully understood by users, it still might not, as currently designed, provide effective protection.
Browsing the web involves reading text, clicking hyperlinks and filling out forms; all activities which take place entirely within the web page area of the browser window. Consequently, studies have shown that users rarely consult the chrome, instead focusing on the task at hand. Even when the chrome has not been tampered with and is providing the intended presentation, it goes unnoticed by users [Security Toolbars], [Why Phishing Works].
Current chrome decorates web pages that provide security information, and remains silent about those that provide none. This design creates multiple problems.
It is difficult for humans to react to the absence of something. Studies have shown that users do not reliably notice the absence of security indicators [Why Phishing Works].
Users, and even experts, commonly attribute more security than is warranted to a web page that is not protected by SSL. A login form on such a page can be readily modified in transit such that it will send the user's login credentials to an attacker before logging the user into the authentic web site.
Desktop software commonly reports problems through modal pop-up dialog boxes. Such dialog boxes frequently appear during normal software use. Also, the user is frequently given no reasonable course of action other than clicking the OK button. Consequently, users have been conditioned to automatically dismiss such dialog boxes, often without even glancing at their content. User studies confirm this phenomena also holds for security warnings from web browsers [Why Phishing Works].
Though research incorporating usable security goes back to the principle of "psychological acceptability" from Saltzer and Schroeder [Saltzer and Schroeder], making security usable is still a nascent area for research [Security and Usability]. There are no worked examples of formal standards from standards making bodies on usable security to emulate. There are a limited number of worked examples in deployed products to learn from. There are a larger number of attempts with unclear results to learn from. We have yet to get widely-applicable, satisfactory answers to basic questions on usable security. Consequently, this Working Group's recommendations will necessarily contain more innovation than might a traditional standards effort. This section details the process the Working Group will employ to mitigate the significant perils of innovation in a standards effort.
By its very nature, the public reviews of the deliverables of this Working Group via the W3C standards process will provide pertinent and timely input from researchers and practitioners in a variety of disciplines, including usability and design, security, and accessibility. That feedback may be based on experience with other standards efforts, experience prototyping or developing software or devices, experience with deployment or use of software or devices, or other forms of anecdotal evidence. This data represents experience and knowledge that has not been or cannot be captured via document principles, previous studies, or the working group's testing. The Working Group will use such feedback to inform our recommendations.
Though principles and examples of usable security are scarce, expertise on the general usability of software is more plentiful. Principles of usability aim to help the user understand presented information, discover the actions that can be taken, predict the implications of those actions and so learn how the tool can be made to serve the user's needs. These aims are also a prerequisite for usable security. Listed below are design principles, drawn from the research literature, recognized by the Working Group as relevant to usable security.
An element of a user interface should include cues that help the user discover its features [Design of Everyday Things].
A user will develop a personal model of what something does and how it works. The user interface should present cues that assist the formation of this model and ensure that the actual and perceived state of the system are consistent [Design of Everyday Things].
The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order [Ten Usability Heuristics].
Persistent use of any interface will cause the user to develop habits. A user interface should leverage habit formation to shape the user's workflow [Humane Interface].
A user has only a single locus of attention, a feature or an object in the physical world, or an idea, about which they are intently and actively thinking. Humans ignore things that aren't their current locus of attention. The user's locus of attention is only held in short term memory and so will be quickly forgotten once their attention shifts. [Humane Interface].
Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility [Ten Usability Heuristics].
Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution [Ten Usability Heuristics].
If the user is expected to carry out a task or an action to achieve the desired level of security, they should have access to an explanation that justifies why it is necessary.
Design should begin with an understanding of the intended users. This includes population profiles that reflect training, motivation, and goals [Designing the User Interface].
With the intended user in mind, designers should formally write down user tasks [Designing the User Interface].
The cues should be displayed consistently in location and across sites and web user agents in an attempt to prevent spoofing and user confusion. [Designing the User Interface].
A growing body of research documents presentation techniques that have not proved effective in providing usable security. The results of these studies will be used to judge the expected effectiveness of presentation techniques. The Working Group will keep abreast of ongoing studies and subject potential recommendations to review by usability experts from both inside the Working Group, and from outside.
Section 9 Problems with the status quo contains a summary of much of what has been learned about phishing. Additional results are listed below.
In Why Phishing Works [Why Phishing Works], neither education, age, sex, previous experience, nor hours of computer use showed a statistically significant correlation with vulnerability to phishing.
The user must be aware that a decision is to be made, what information should be used to make the decision, and where to look for the information [Johnny].
Part of a Working Group's activities is developing code and test suites [W3C Process].
The Working Group aims to demonstrate and test the WG's recommendations on usable and robust communication of security context information through implementations within the framework of one or more web user agents. The most likely web user agents to serve as platforms for such implementations are web browsers. To demonstrate that recommendations are sufficiently general and interoperable, we expect implementation in the context of at least two web user agents.
We are targetting three types of testing of our recommendations: functional testing, robustness testing, and usability testing [W3C Testing].
All test development and testing is iterative. The recommendations may need to be modified on the basis of all three types of testing. Test development starts when work on the specification starts. Test planning will include guidelines for developing tests. Test suites are typically developed when the specifications are in a reasonably stable state, such as the first full public working draft. Test development will include test execution instructions. Automation of the tests will be considered but is unlikely, as the tests will require human visual confirmation. Clear descriptions of what to expect and how to judge outcome will be part of each test.
Functional testing against the sample code and appropriate deployment configurations will verify that the recommendations can be translated to web user agent code, with no functional ill effects on the rest of the web user agent. It will show that implementations can conform to the recommendations, and that the specifications clearly define behaviors. This is also called conformance testing.
Robustness testing will verify that the recommendations are robust against spoofing attacks. Existing spoofing attacks will be documented, and new spoofing attacks aimed directly at the recommendations (both required and recommended) will be developed. All of these attacks will take the form of web site content returned to the user agent (most typically DHTML or XML that a web browser GETs).
Usability testing will verify that the recommendations provide usable display of security context information. The type of usability testing we do will depend on both the direction of our recommendations and the resources the Working Group is able to tap into. The Working Group aims to perform lo fidelity prototyping and testing with a modest number of test subjects (10 - 20) for each proposed practice that involves user feedback [Tiny Fingers]. This will be reflected in Candidate Recommendation exit criteria. Prototyping at this level will provide feedback in early design phases at a point where needed changes can be made easily. It will also create a more user-centered design process and will help in the realization of our goals that address usability.
More extensive user testing will be desirable, and is expected to contribute to higher-quality outcomes. More extensive tests may include:
Incremental testing incorporating feedback from previous iterations
Recruiting participants from broader groups which better represent target user groups, either in size or relevant characteristics
Lab testing of sample code, for example [Johnny 2]
Contextual or "in the wild" testing of sample code [Social Phishing]
More iterative combinations of the above, throughout the specification lifecycle
This note is based on input from Tyler Close, Thomas Roessler, Mary Ellen Zurko, Bill Doyle, Maritza Johnson, Phill Hallam-Baker, Hal Lockhart, Brad Porter, Dan Schutzer, Stephen Farrell, Stuart Schechter, Tim Hahn, Luis Barriga, Mike Beltzner, Al Gilman, Rich Salz, Ian Fette, and the members of the Web Security Context Working Group. It has also benefitted from general public and working group commentary on earlier drafts.


This is intended for code blocks (

) and not for inline code.
Add class command-line to your

. For a server command line, specify the user and host names using the data-user
and data-host
attributes. The resulting prompt displays a # for the root user and $ for all other users. For any other command line, such as a Windows prompt, you may specify the entire prompt using the data-prompt
attribute.
You may specify the lines to be presented as output (no prompt and no highlighting) through the data-output
attribute on the

element in the following simple format:
Examples:
To automatically present some lines as output, you can prefix those lines with any string and specify the prefix using the data-filter-output
attribute on the

element. For example, data-filter-output="(out)"
will treat lines beginning with (out)
as output and remove the prefix.
A blank line will render as an empty line with a prompt. If you want an empty line without a prompt then you can use a line containing just the output prefix, e.g. (out)
. See the blank lines in the examples below.
Output lines are user selectable by default, so if you select the whole content of the code block, it will select the shell commands and any output lines. This may not be desirable if you want to copy/paste just the commands and not the output. If you want to make the output not user selectable then add the following to your CSS:
.command-line span.token.output {
user-select: none;
}
You can configure the plugin to handle multi-line commands. This can be done in two ways; setting a line continuation string (as in Bash); or explicitly marking continuation lines with a prefix for languages that do not have a continuation string/character, e.g. SQL, Scala, etc..
data-continuation-str
data-continuation-str="\"
data-filter-continuation
data-filter-output
. Prefix all continuation lines with the value of data-filter-continuation
and they will be displayed with the prompt set in data-continuation-prompt
. For example, data-filter-continuation="(con)"
will treat lines beginning with (con)
as continuation lines and remove the prefix.data-continuation-prompt
data-continuation-prompt="->"
.
Write-Host 'Goodbye from PowerShell!'
(out)Goodbye from PowerShell!

"
data-continuation-prompt="->"
data-filter-output="(out)"
data-filter-continuation="(con)">
set @my_var = 'foo';
set @my_other_var = 'bar';
(out)
CREATE TABLE people (
(con)first_name VARCHAR(30) NOT NULL,
(con)last_name VARCHAR(30) NOT NULL
(con));
(out)Query OK, 0 rows affected (0.09 sec)
(out)
insert into people
(con)values ('John', 'Doe');
(out)Query OK, 1 row affected (0.02 sec)
(out)
select *
(con)from people
(con)order by last_name;
(out)+------------+-----------+
(out)| first_name | last_name |
(out)+------------+-----------+
(out)| John | Doe |
(out)+------------+-----------+
(out)1 row in set (0.00 sec)


Beautiful E-Commerce Shop
list
ALL
DRESSES
TOPS
BOTTOMS
ROMPERS
ACCESSORIES
SOAPS & SCRUBS
shopping_basket
DRESSES
TOPS
BOTTOMS
ROMPERS
ACCESSORIES
BODY
shopping_basket
{{selectedProduct.productTitle}}
PRICE
${{selectedProduct.price}}
{{selectedProduct.productDescription}}
COLOR
Select color
{{colorOption.color}}
S
M
L
ADD TO BAG
ADD TO BAG
SOLD OUT
| WANT THIS BACK IN THE SHOP ?
Thanks! We will keep you in the loop.
ADD TO BAG
L
L
M
M
S
S
SOLD OUT
> WANT THIS BACK IN THE SHOP ?
ADD TO BAG
{{product.productTitle}}
${{ product.price }}
SHOPPING BAG
NO ITEMS IN YOUR CART
{{product.name}}
SIZE
{{product.size}}
OS
COLOR
{{product.color}}
PRICE
${{product.price}}
X
TOTAL: ${{total}}
CHECKOUT