M1654: Improve network security features for Servo (cookies and strict referrer policies)
 
=='''Introduction'''==
=== Servo ===
[https://servo.org/ Servo] is a modern high-performance browser engine designed for both application and embedded use which is written in Rust. It is created by Mozilla Research and is being built by a global community of individual contributors and companies such as Mozilla and Samsung.

Task Communication Diagram

[[File:Tasks1.jpg]]

=== HTTP Cookie ===
An [https://en.wikipedia.org/wiki/HTTP_cookie HTTP Cookie] is a small part of data which is sent by the website to the user's computer and is stored by the user's web browser while the user is browsing. A cookie is mainly used for recording a user's browsing activity or to remember stateful information for the websites.

=== Rust ===
[https://doc.rust-lang.org/book/ Rust] is a systems programming language developed and maintained by Mozilla. It is used as a multi-paradigm, compiled programming language for creating highly safe systems. Rust can be used for a variety of jobs including and not restricted to embedding into other languages, creating modular and optimized programs adhering to space-time constraints and can also be used to develop low-level code for writing device drivers.

=='''Project Description'''==
The goal of this project is to implement newer, more secure standards, and complete missing pieces of existing ones, in order to increase the security available to users of the Servo browser. The project entails adding improved network security features for Servo engine by implementing a maximum number of cookies per host, and restricting insecure cookies from overwriting secure ones. The initial steps for this project have been completed as part of the OSS Project.

=='''Tasks'''==

1) Compile Servo and ensure that it runs on tests/html/about-mozilla.html

2) Redesign CookieStorage to store cookies in a HashMap where the key is the base domain of the cookie's source (ie. "www.google.co.uk" becomes "google.co.uk")

3) Store a max_per_host limit in CookieStorage that is checked when adding new cookies; evict the oldest cookie if the limit is reached (add tests to tests/unit/net/cookie.rs)

4) Implement the [https://datatracker.ietf.org/doc/draft-ietf-httpbis-cookie-alone/?include_text=1 Leave Secure Cookies Alone] specification - ensure that newly created insecure cookies cannot override existing secure cookies (add tests to tests/unit/net/cookie.rs)

Current Structure 
[[File:Cookie_before.JPG]]
 
After Refactoring 
[[File:Cookie_after.JPG]]

The current implementation of CookieStorage utilizes vector of Cookies. No restrictions are placed on the number of cookies that can be added per host.The proposed change will refactor CookieStorage to use HashMap with Base host as key. There would a limit on the maximum number of cookies per host. Changes will also include, implementation of '''Deprecate modification of 'secure' cookies from non-secure origins''' which update RFC6265 by removing the ability for a non-secure origin to set cookies with a 'secure' flag, and to overwrite cookies whose 'secure' flag is set.

Since this contains refactoring, all existing unit testcases need to pass. Additionally, new unit test cases will be written for validating implementation of aforementioned specific order for a action.

=='''Approach'''==
First step would be to update the vector to HasMap by maintaining the wrapper functions used on the CookieStporage class. Upon completion of the task, all the unit test cases should pass. This would provide an additional checkpoint to verify the integrity of the new CookieStorage class's behavior.

Subsequent steps would include refactoring of the code so that the existing functionality is retained with added feature and advantages provided by HashMaps like faster search.

RFC implementation would be possible after the code refactoring of CookieStorage class. Most of the RFC related changes are related to maintaining the content of the map. So this step would be a penultimate step of the project.

Team would follow Test Driven Development, so unit tests would be written first wherever required and production code would be written to make the testcases pass.

We would follow Pair Programming to minimize errors and maximize the productivity. We are going to adhere to industry set standards which provide better QoS and stable product.

=='''Continuous Integration'''==
Continuous Integration, being a key element in Test Driven Development. Our team will setup our own Travis server to ensure code sanity.
=='''Testing'''==
We have implemented the following scenarios to test the cookie eviction and max_per_host features:
<ol>
<li>Evict expired cookies when max per host is reached: In this scenario, we delete all the expired cookies from Cookie Store when number of cookies in the base domain reaches maximum threshold (max_per_host)</li>
<li>Evict oldest non-secure cookie: When there are no expired cookie in the cookie storage and maximum threshold has been reached (max_per_host), then the oldest non-secure cookie is evicted out.</li>
<li>Do not evict secure cookie when maximum threshold is reached (max_per_host) when new cookie being added is non-secure.</li>
<li>Evict oldest secure cookie when all cookies in the Cookie Storage are secure and the incoming cookie is also a secure cookie.</li>
</ol>

All the aforementioned scenario have been implemented as unit tests. In order to test it please use the following commands:

<code>
./mach build --dev
./mach test-unit -p net
</code>

Manual testing from UI:
This is not part of required tasks and has been implemented purely for demonstration purpose.

<code>
./mach run https://coookietester.herokuapp.com/cookies
</code>

[[File:CookieTester.jpg|center]]

=='''Files modified'''==
* /servo/components/cookie_storage.rs
* /servo/components/net/cookie.rs
* /servo/test/unit/cookie.rs
* /servo/components/servo/cargo.toml
* /servo/components/servo/cargo.lock
* /servo/components/net/http_loader.rs
* /servo/components/net/resource_thread.rs

=='''Design'''==
In the images below, the code changes reflect the code refactoring involved in changing vector implementation to a HashMap implementation. Another important feature to notice is the addition of a new parameter for the Cookie Storage constructor. This value max_per_host dictates how many cookies per domain is supported by servo. For testing the value has been set to 5 and for production, the value has been set to 150 (as per Mozilla Team's guidelines). Whenever a new cookie is added, the cookie's base domain name is extracted out and is looked up in the HashMap. If no entry is found a new Vector is created and appended to it.
 
When the number of cookies for a base domain reaches the maximum set limit (max_per_host), eviction policy is used to decide the cookies which need to be eliminated to accommodate the new cookie. In order for a non-secure cookie to not replace secure cookie, the following priority order is used while deciding to evict a cookie(s):
<ol>
<li> Expired cookies.
<li> Cookies whose "secure-only-flag" is not set and which share a "domain" field with more than a predetermined number of other cookies.
<li> Cookies that share a "domain" field with more than a predetermined number of other cookies.
<li> All cookies.
</ol>
 
[[File:Eviction_flowchart.JPG]]
 
A preview of the file diffs is as shown below. Complete file diffs are available at this [https://github.com/servo/servo/pull/14445/files link].
 
[[File:Cs1.jpg]]
 
[[File:Cs2.jpg]]

=='''Key People'''==
=== Developers ===
* Guru Darshan
* Raghavendra Nayak
* Rishi Jain
* Tsung-Ying Chuang
=== Mentor ===
* Ed Gehringer

File:CookieTester.jpg

2016-12-12T16:47:16Z

Gpollep: uploaded a new version of "File:CookieTester.jpg"

File:CookieTester.jpg

2016-12-12T16:46:00Z

Gpollep:

User:Rjain9

2016-12-12T16:27:36Z

Gpollep: /* Design */

M1654: Improve network security features for Servo (cookies and strict referrer policies)
 
=='''Introduction'''==
=== Servo ===
[https://servo.org/ Servo] is a modern high-performance browser engine designed for both application and embedded use which is written in Rust. It is created by Mozilla Research and is being built by a global community of individual contributors and companies such as Mozilla and Samsung.

Task Communication Diagram

[[File:Tasks1.jpg]]

=== HTTP Cookie ===
An [https://en.wikipedia.org/wiki/HTTP_cookie HTTP Cookie] is a small part of data which is sent by the website to the user's computer and is stored by the user's web browser while the user is browsing. A cookie is mainly used for recording a user's browsing activity or to remember stateful information for the websites.

=== Rust ===
[https://doc.rust-lang.org/book/ Rust] is a systems programming language developed and maintained by Mozilla. It is used as a multi-paradigm, compiled programming language for creating highly safe systems. Rust can be used for a variety of jobs including and not restricted to embedding into other languages, creating modular and optimized programs adhering to space-time constraints and can also be used to develop low-level code for writing device drivers.

=='''Project Description'''==
The goal of this project is to implement newer, more secure standards, and complete missing pieces of existing ones, in order to increase the security available to users of the Servo browser. The project entails adding improved network security features for Servo engine by implementing a maximum number of cookies per host, and restricting insecure cookies from overwriting secure ones. The initial steps for this project have been completed as part of the OSS Project.

=='''Tasks'''==

1) Compile Servo and ensure that it runs on tests/html/about-mozilla.html

2) Redesign CookieStorage to store cookies in a HashMap where the key is the base domain of the cookie's source (ie. "www.google.co.uk" becomes "google.co.uk")

3) Store a max_per_host limit in CookieStorage that is checked when adding new cookies; evict the oldest cookie if the limit is reached (add tests to tests/unit/net/cookie.rs)

4) Implement the [https://datatracker.ietf.org/doc/draft-ietf-httpbis-cookie-alone/?include_text=1 Leave Secure Cookies Alone] specification - ensure that newly created insecure cookies cannot override existing secure cookies (add tests to tests/unit/net/cookie.rs)

Current Structure 
[[File:Cookie_before.JPG]]
 
After Refactoring 
[[File:Cookie_after.JPG]]

The current implementation of CookieStorage utilizes vector of Cookies. No restrictions are placed on the number of cookies that can be added per host.The proposed change will refactor CookieStorage to use HashMap with Base host as key. There would a limit on the maximum number of cookies per host. Changes will also include, implementation of '''Deprecate modification of 'secure' cookies from non-secure origins''' which update RFC6265 by removing the ability for a non-secure origin to set cookies with a 'secure' flag, and to overwrite cookies whose 'secure' flag is set.

Since this contains refactoring, all existing unit testcases need to pass. Additionally, new unit test cases will be written for validating implementation of aforementioned specific order for a action.

=='''Approach'''==
First step would be to update the vector to HasMap by maintaining the wrapper functions used on the CookieStporage class. Upon completion of the task, all the unit test cases should pass. This would provide an additional checkpoint to verify the integrity of the new CookieStorage class's behavior.

Subsequent steps would include refactoring of the code so that the existing functionality is retained with added feature and advantages provided by HashMaps like faster search.

RFC implementation would be possible after the code refactoring of CookieStorage class. Most of the RFC related changes are related to maintaining the content of the map. So this step would be a penultimate step of the project.

Team would follow Test Driven Development, so unit tests would be written first wherever required and production code would be written to make the testcases pass.

We would follow Pair Programming to minimize errors and maximize the productivity. We are going to adhere to industry set standards which provide better QoS and stable product.

=='''Continuous Integration'''==
Continuous Integration, being a key element in Test Driven Development. Our team will setup our own Travis server to ensure code sanity.
==Test Plan==
There is no manual testing in this project. Existing unit tests will ensure that refactoring has not broken any functionality. New unit test cases would be written for validating "Leave Secure Cookies Alone" specification.

1) Unit test for checking "secure-only-flag" is set.
2) Unit test for "domain" domain-matches the "domain" of the newly created cookie, or vice-versa.
3) Unit test to validate The "path" of the newly created cookie path-matches the "path" of the existing cookie.

Please note that since lot of unit tests are already in place. We are not required to write many new test cases. After refactoring, if CI passes without any dip in code coverage then we can say refactoring is successful.
=='''Files modified'''==
* /servo/components/cookie_storage.rs
* /servo/components/net/cookie.rs
* /servo/test/unit/cookie.rs
* /servo/components/servo/cargo.toml
* /servo/components/servo/cargo.lock
* /servo/components/net/http_loader.rs
* /servo/components/net/resource_thread.rs

=='''Design'''==
In the images below, the code changes reflect the code refactoring involved in changing vector implementation to a HashMap implementation. Another important feature to notice is the addition of a new parameter for the Cookie Storage constructor. This value max_per_host dictates how many cookies per domain is supported by servo. For testing the value has been set to 5 and for production, the value has been set to 150 (as per Mozilla Team's guidelines). Whenever a new cookie is added, the cookie's base domain name is extracted out and is looked up in the HashMap. If no entry is found a new Vector is created and appended to it.
 
When the number of cookies for a base domain reaches the maximum set limit (max_per_host), eviction policy is used to decide the cookies which need to be eliminated to accommodate the new cookie. In order for a non-secure cookie to not replace secure cookie, the following priority order is used while deciding to evict a cookie(s):
<ol>
<li> Expired cookies.
<li> Cookies whose "secure-only-flag" is not set and which share a "domain" field with more than a predetermined number of other cookies.
<li> Cookies that share a "domain" field with more than a predetermined number of other cookies.
<li> All cookies.
</ol>
 
[[File:Eviction_flowchart.JPG]]
 
A preview of the file diffs is as shown below. Complete file diffs are available at this [https://github.com/servo/servo/pull/14445/files link].
 
[[File:Cs1.jpg]]
 
[[File:Cs2.jpg]]

=='''Key People'''==
=== Developers ===
* Guru Darshan
* Raghavendra Nayak
* Rishi Jain
* Tsung-Ying Chuang
=== Mentor ===
* Ed Gehringer

User:Rjain9

2016-12-12T16:26:54Z

Gpollep: /* Code Changes */

M1654: Improve network security features for Servo (cookies and strict referrer policies)
 
=='''Introduction'''==
=== Servo ===
[https://servo.org/ Servo] is a modern high-performance browser engine designed for both application and embedded use which is written in Rust. It is created by Mozilla Research and is being built by a global community of individual contributors and companies such as Mozilla and Samsung.

Task Communication Diagram

[[File:Tasks1.jpg]]

=== HTTP Cookie ===
An [https://en.wikipedia.org/wiki/HTTP_cookie HTTP Cookie] is a small part of data which is sent by the website to the user's computer and is stored by the user's web browser while the user is browsing. A cookie is mainly used for recording a user's browsing activity or to remember stateful information for the websites.

=== Rust ===
[https://doc.rust-lang.org/book/ Rust] is a systems programming language developed and maintained by Mozilla. It is used as a multi-paradigm, compiled programming language for creating highly safe systems. Rust can be used for a variety of jobs including and not restricted to embedding into other languages, creating modular and optimized programs adhering to space-time constraints and can also be used to develop low-level code for writing device drivers.

=='''Project Description'''==
The goal of this project is to implement newer, more secure standards, and complete missing pieces of existing ones, in order to increase the security available to users of the Servo browser. The project entails adding improved network security features for Servo engine by implementing a maximum number of cookies per host, and restricting insecure cookies from overwriting secure ones. The initial steps for this project have been completed as part of the OSS Project.

=='''Tasks'''==

1) Compile Servo and ensure that it runs on tests/html/about-mozilla.html

2) Redesign CookieStorage to store cookies in a HashMap where the key is the base domain of the cookie's source (ie. "www.google.co.uk" becomes "google.co.uk")

3) Store a max_per_host limit in CookieStorage that is checked when adding new cookies; evict the oldest cookie if the limit is reached (add tests to tests/unit/net/cookie.rs)

4) Implement the [https://datatracker.ietf.org/doc/draft-ietf-httpbis-cookie-alone/?include_text=1 Leave Secure Cookies Alone] specification - ensure that newly created insecure cookies cannot override existing secure cookies (add tests to tests/unit/net/cookie.rs)

Current Structure 
[[File:Cookie_before.JPG]]
 
After Refactoring 
[[File:Cookie_after.JPG]]

The current implementation of CookieStorage utilizes vector of Cookies. No restrictions are placed on the number of cookies that can be added per host.The proposed change will refactor CookieStorage to use HashMap with Base host as key. There would a limit on the maximum number of cookies per host. Changes will also include, implementation of '''Deprecate modification of 'secure' cookies from non-secure origins''' which update RFC6265 by removing the ability for a non-secure origin to set cookies with a 'secure' flag, and to overwrite cookies whose 'secure' flag is set.

Since this contains refactoring, all existing unit testcases need to pass. Additionally, new unit test cases will be written for validating implementation of aforementioned specific order for a action.

=='''Approach'''==
First step would be to update the vector to HasMap by maintaining the wrapper functions used on the CookieStporage class. Upon completion of the task, all the unit test cases should pass. This would provide an additional checkpoint to verify the integrity of the new CookieStorage class's behavior.

Subsequent steps would include refactoring of the code so that the existing functionality is retained with added feature and advantages provided by HashMaps like faster search.

RFC implementation would be possible after the code refactoring of CookieStorage class. Most of the RFC related changes are related to maintaining the content of the map. So this step would be a penultimate step of the project.

Team would follow Test Driven Development, so unit tests would be written first wherever required and production code would be written to make the testcases pass.

We would follow Pair Programming to minimize errors and maximize the productivity. We are going to adhere to industry set standards which provide better QoS and stable product.

=='''Continuous Integration'''==
Continuous Integration, being a key element in Test Driven Development. Our team will setup our own Travis server to ensure code sanity.
==Test Plan==
There is no manual testing in this project. Existing unit tests will ensure that refactoring has not broken any functionality. New unit test cases would be written for validating "Leave Secure Cookies Alone" specification.

1) Unit test for checking "secure-only-flag" is set.
2) Unit test for "domain" domain-matches the "domain" of the newly created cookie, or vice-versa.
3) Unit test to validate The "path" of the newly created cookie path-matches the "path" of the existing cookie.

Please note that since lot of unit tests are already in place. We are not required to write many new test cases. After refactoring, if CI passes without any dip in code coverage then we can say refactoring is successful.
=='''Files modified'''==
* /servo/components/cookie_storage.rs
* /servo/components/net/cookie.rs
* /servo/test/unit/cookie.rs
* /servo/components/servo/cargo.toml
* /servo/components/servo/cargo.lock
* /servo/components/net/http_loader.rs
* /servo/components/net/resource_thread.rs

=='''Design'''==
In the images below, the changes reflect the code refactoring involved in changing linked list implementation to a HashMap implementation. Another important feature to notice is the addition of a new parameter for the Cookie Storage constructor. This value max_per_host dictates how many cookies per domain is supported by servo. For testing the value has been set to 5 and for production, the value has been set to 150 (as per Mozilla Team's guidelines). Whenever a new cookie is added, the cookie's base domain name is extracted out and is looked up in the HashMap. If no entry is found a new Vector is created and appended to it.
 
When the number of cookies for a base domain reaches the maximum set limit (max_per_host), eviction policy is used to decide the cookies which need to be eliminated to accommodate the new cookie. In order for a non-secure cookie to not replace secure cookie, the following priority order is used while deciding to evict a cookie(s):
<ol>
<li> Expired cookies.
<li> Cookies whose "secure-only-flag" is not set and which share a "domain" field with more than a predetermined number of other cookies.
<li> Cookies that share a "domain" field with more than a predetermined number of other cookies.
<li> All cookies.
</ol>
 
[[File:Eviction_flowchart.JPG]]
 
A preview of the file diffs is as shown below. Complete file diffs are available at this [https://github.com/servo/servo/pull/14445/files link].
 
[[File:Cs1.jpg]]
 
[[File:Cs2.jpg]]

=='''Key People'''==
=== Developers ===
* Guru Darshan
* Raghavendra Nayak
* Rishi Jain
* Tsung-Ying Chuang
=== Mentor ===
* Ed Gehringer

User:Rjain9

2016-12-12T13:10:54Z

2016-12-11T21:55:18Z

Gpollep: /* Code Changes */

M1654: Improve network security features for Servo (cookies and strict referrer policies)
 
=='''Introduction'''==
=== Servo ===
[https://servo.org/ Servo] is a modern high-performance browser engine designed for both application and embedded use which is written in Rust. It is created by Mozilla Research and is being built by a global community of individual contributors and companies such as Mozilla and Samsung.

Task Communication Diagram

[[File:Tasks1.jpg]]

=== HTTP Cookie ===
An [https://en.wikipedia.org/wiki/HTTP_cookie HTTP Cookie] is a small part of data which is sent by the website to the user's computer and is stored by the user's web browser while the user is browsing. A cookie is mainly used for recording a user's browsing activity or to remember stateful information for the websites.

=== Rust ===
[https://doc.rust-lang.org/book/ Rust] is a systems programming language developed and maintained by Mozilla. It is used as a multi-paradigm, compiled programming language for creating highly safe systems. Rust can be used for a variety of jobs including and not restricted to embedding into other languages, creating modular and optimized programs adhering to space-time constraints and can also be used to develop low-level code for writing device drivers.

=='''Project Description'''==
The goal of this project is to implement newer, more secure standards, and complete missing pieces of existing ones, in order to increase the security available to users of the Servo browser. The project entails adding improved network security features for Servo engine by implementing a maximum number of cookies per host, and restricting insecure cookies from overwriting secure ones. The initial steps for this project have been completed as part of the OSS Project.

=='''Tasks'''==

1) Compile Servo and ensure that it runs on tests/html/about-mozilla.html

2) Redesign CookieStorage to store cookies in a HashMap where the key is the base domain of the cookie's source (ie. "www.google.co.uk" becomes "google.co.uk")

3) Store a max_per_host limit in CookieStorage that is checked when adding new cookies; evict the oldest cookie if the limit is reached (add tests to tests/unit/net/cookie.rs)

4) Implement the [https://datatracker.ietf.org/doc/draft-ietf-httpbis-cookie-alone/?include_text=1 Leave Secure Cookies Alone] specification - ensure that newly created insecure cookies cannot override existing secure cookies (add tests to tests/unit/net/cookie.rs)

Current Structure 
[[File:Cookie_before.JPG]]
 
After Refactoring 
[[File:Cookie_after.JPG]]

The current implementation of CookieStorage utilizes vector of Cookies. No restrictions are placed on the number of cookies that can be added per host.The proposed change will refactor CookieStorage to use HashMap with Base host as key. There would a limit on the maximum number of cookies per host. Changes will also include, implementation of '''Deprecate modification of 'secure' cookies from non-secure origins''' which update RFC6265 by removing the ability for a non-secure origin to set cookies with a 'secure' flag, and to overwrite cookies whose 'secure' flag is set.

Since this contains refactoring, all existing unit testcases need to pass. Additionally, new unit test cases will be written for validating implementation of aforementioned specifi order for a cation.

In order for a non-secure cookie to not replace secure cookie, the following priority order is used while deciding to evict a cookie(s):

<ol>
<li> Expired cookies.
<li> Cookies whose "secure-only-flag" is not set and which share a "domain" field with more than a predetermined number of other cookies.
<li> Cookies that share a "domain" field with more than a predetermined number of other cookies.
<li> All cookies.
</ol>

=='''Approach'''==
First step would be to update the vector to HasMap by maintaining the wrapper functions used on the CookieStporage class. Upon completion of the task, all the unit test cases should pass. This would provide an additional checkpoint to verify the integrity of the new CookieStorage class's behavior.

Subsequent steps would include refactoring of the code so that the existing functionality is retained with added feature and advantages provided by HashMaps like faster search.

RFC implementation would be possible after the code refactor of CookieStorage class. Most of the RFC related changes are related to maintaining the content of the map. So this step would be penultimate step of the project.

Team would follow Test Driven Development, so unit tests would be written first wherever required and production code would be written to make the testcases pass.

We would follow Pair Programming to minimize errors and maximize the productivity. We are going to adhere to industry set standards which provide better QoS and stable product.

=='''Continuous Integration'''==
Continuous Integration, being a key element in Test Driven Development. Our team will setup our own Travis server to ensure code sanity.
==Test Plan==
There is no manual testing in this project. Existing unit tests will ensure that refactoring has not broken any functionality. New unit test cases would be written for validating "Leave Secure Cookies Alone" specification.

1) Unit test for checking "secure-only-flag" is set.
2) Unit test for "domain" domain-matches the "domain" of the newly created cookie, or vice-versa.
3) Unit test to validate The "path" of the newly created cookie path-matches the "path" of the existing cookie.

Please note that since lot of unit tests are already in place. We are not required to write many new test cases. After refactoring, if CI passes without any dip in code coverage then we can say refactoring is successful.
=='''Files modified'''==
* /servo/components/cookie_storage.rs
* /servo/components/net/cookie.rs
* /servo/test/unit/cookie.rs
* /servo/components/servo/cargo.toml
* /servo/components/servo/cargo.lock
* /servo/components/net/http_loader.rs
* /servo/components/net/resource_thread.rs

=='''Code Changes'''==
In the images below, the changes reflect the code refactoring involved in changing linked list implementation to a HashMap implementation. Another important feature to notice is the addition of a new parameter for the Cookie Storage constructor. This value max_per_host dictates how many cookies per domain is supported by servo. For testing the value has been set to 5 and for production, the value has been set to 150 (as per Mozilla Team's guidelines). Whenever a new cookie is added, the cookie's base domain name is extracted out and is looked up in the HashMap. If no entry is found a new Vector is created and appended to it.

When the number of cookies for a base domain reach the maximum set limit (max_per_host), eviction policy is used to decide the cookies which need to be eliminated to accommodate the new cookie.
 
[[File:Cs1.jpg]]
 

=='''Key People'''==
=== Developers ===
* Guru Darshan
* Raghavendra Nayak
* Rishi Jain
* Tsung-Ying Chuang
=== Mentor ===
* Ed Gehringer

User:Rjain9

2016-12-11T21:53:41Z

Gpollep: /* Code Changes */

M1654: Improve network security features for Servo (cookies and strict referrer policies)
 
=='''Introduction'''==
=== Servo ===
[https://servo.org/ Servo] is a modern high-performance browser engine designed for both application and embedded use which is written in Rust. It is created by Mozilla Research and is being built by a global community of individual contributors and companies such as Mozilla and Samsung.

Task Communication Diagram

[[File:Tasks1.jpg]]

=== HTTP Cookie ===
An [https://en.wikipedia.org/wiki/HTTP_cookie HTTP Cookie] is a small part of data which is sent by the website to the user's computer and is stored by the user's web browser while the user is browsing. A cookie is mainly used for recording a user's browsing activity or to remember stateful information for the websites.

=== Rust ===
[https://doc.rust-lang.org/book/ Rust] is a systems programming language developed and maintained by Mozilla. It is used as a multi-paradigm, compiled programming language for creating highly safe systems. Rust can be used for a variety of jobs including and not restricted to embedding into other languages, creating modular and optimized programs adhering to space-time constraints and can also be used to develop low-level code for writing device drivers.

=='''Project Description'''==
The goal of this project is to implement newer, more secure standards, and complete missing pieces of existing ones, in order to increase the security available to users of the Servo browser. The project entails adding improved network security features for Servo engine by implementing a maximum number of cookies per host, and restricting insecure cookies from overwriting secure ones. The initial steps for this project have been completed as part of the OSS Project.

=='''Tasks'''==

1) Compile Servo and ensure that it runs on tests/html/about-mozilla.html

2) Redesign CookieStorage to store cookies in a HashMap where the key is the base domain of the cookie's source (ie. "www.google.co.uk" becomes "google.co.uk")

3) Store a max_per_host limit in CookieStorage that is checked when adding new cookies; evict the oldest cookie if the limit is reached (add tests to tests/unit/net/cookie.rs)

4) Implement the [https://datatracker.ietf.org/doc/draft-ietf-httpbis-cookie-alone/?include_text=1 Leave Secure Cookies Alone] specification - ensure that newly created insecure cookies cannot override existing secure cookies (add tests to tests/unit/net/cookie.rs)

Current Structure 
[[File:Cookie_before.JPG]]
 
After Refactoring 
[[File:Cookie_after.JPG]]

The current implementation of CookieStorage utilizes vector of Cookies. No restrictions are placed on the number of cookies that can be added per host.The proposed change will refactor CookieStorage to use HashMap with Base host as key. There would a limit on the maximum number of cookies per host. Changes will also include, implementation of '''Deprecate modification of 'secure' cookies from non-secure origins''' which update RFC6265 by removing the ability for a non-secure origin to set cookies with a 'secure' flag, and to overwrite cookies whose 'secure' flag is set.

Since this contains refactoring, all existing unit testcases need to pass. Additionally, new unit test cases will be written for validating implementation of aforementioned specifi order for a cation.

In order for a non-secure cookie to not replace secure cookie, the following priority order is used while deciding to evict a cookie(s):

<ol>
<li> Expired cookies.
<li> Cookies whose "secure-only-flag" is not set and which share a "domain" field with more than a predetermined number of other cookies.
<li> Cookies that share a "domain" field with more than a predetermined number of other cookies.
<li> All cookies.
</ol>

=='''Approach'''==
First step would be to update the vector to HasMap by maintaining the wrapper functions used on the CookieStporage class. Upon completion of the task, all the unit test cases should pass. This would provide an additional checkpoint to verify the integrity of the new CookieStorage class's behavior.

Subsequent steps would include refactoring of the code so that the existing functionality is retained with added feature and advantages provided by HashMaps like faster search.

RFC implementation would be possible after the code refactor of CookieStorage class. Most of the RFC related changes are related to maintaining the content of the map. So this step would be penultimate step of the project.

Team would follow Test Driven Development, so unit tests would be written first wherever required and production code would be written to make the testcases pass.

We would follow Pair Programming to minimize errors and maximize the productivity. We are going to adhere to industry set standards which provide better QoS and stable product.

=='''Continuous Integration'''==
Continuous Integration, being a key element in Test Driven Development. Our team will setup our own Travis server to ensure code sanity.
==Test Plan==
There is no manual testing in this project. Existing unit tests will ensure that refactoring has not broken any functionality. New unit test cases would be written for validating "Leave Secure Cookies Alone" specification.

1) Unit test for checking "secure-only-flag" is set.
2) Unit test for "domain" domain-matches the "domain" of the newly created cookie, or vice-versa.
3) Unit test to validate The "path" of the newly created cookie path-matches the "path" of the existing cookie.

Please note that since lot of unit tests are already in place. We are not required to write many new test cases. After refactoring, if CI passes without any dip in code coverage then we can say refactoring is successful.
=='''Files modified'''==
* /servo/components/cookie_storage.rs
* /servo/components/net/cookie.rs
* /servo/test/unit/cookie.rs
* /servo/components/servo/cargo.toml
* /servo/components/servo/cargo.lock
* /servo/components/net/http_loader.rs
* /servo/components/net/resource_thread.rs

=='''Code Changes'''==
In the images above, the changes reflect the code refactoring involved in changing linked list implementation to a HashMap implementation. Another important feature to notice is the addition of a new parameter for the Cookie Storage constructor. This value max_per_host dictates how many cookies per domain is supported by servo. For testing the value has been set to 5 and for production, the value has been set to 150 (as per Mozilla Team's guidelines). Whenever a new cookie is added, the cookie's base domain name is extracted out and is looked up in the HashMap. If no entry is found a new Vector is created and appended to it.
 
[[File:Cs1.jpg]]
 

=='''Key People'''==
=== Developers ===
* Guru Darshan
* Raghavendra Nayak
* Rishi Jain
* Tsung-Ying Chuang
=== Mentor ===
* Ed Gehringer

User:Rjain9

2016-12-11T21:50:58Z

Gpollep: Added description about code changes

M1654: Improve network security features for Servo (cookies and strict referrer policies)
 
=='''Introduction'''==
=== Servo ===
[https://servo.org/ Servo] is a modern high-performance browser engine designed for both application and embedded use which is written in Rust. It is created by Mozilla Research and is being built by a global community of individual contributors and companies such as Mozilla and Samsung.

Task Communication Diagram

[[File:Tasks1.jpg]]

=== HTTP Cookie ===
An [https://en.wikipedia.org/wiki/HTTP_cookie HTTP Cookie] is a small part of data which is sent by the website to the user's computer and is stored by the user's web browser while the user is browsing. A cookie is mainly used for recording a user's browsing activity or to remember stateful information for the websites.

=== Rust ===
[https://doc.rust-lang.org/book/ Rust] is a systems programming language developed and maintained by Mozilla. It is used as a multi-paradigm, compiled programming language for creating highly safe systems. Rust can be used for a variety of jobs including and not restricted to embedding into other languages, creating modular and optimized programs adhering to space-time constraints and can also be used to develop low-level code for writing device drivers.

=='''Project Description'''==
The goal of this project is to implement newer, more secure standards, and complete missing pieces of existing ones, in order to increase the security available to users of the Servo browser. The project entails adding improved network security features for Servo engine by implementing a maximum number of cookies per host, and restricting insecure cookies from overwriting secure ones. The initial steps for this project have been completed as part of the OSS Project.

=='''Tasks'''==

1) Compile Servo and ensure that it runs on tests/html/about-mozilla.html

2) Redesign CookieStorage to store cookies in a HashMap where the key is the base domain of the cookie's source (ie. "www.google.co.uk" becomes "google.co.uk")

3) Store a max_per_host limit in CookieStorage that is checked when adding new cookies; evict the oldest cookie if the limit is reached (add tests to tests/unit/net/cookie.rs)

4) Implement the [https://datatracker.ietf.org/doc/draft-ietf-httpbis-cookie-alone/?include_text=1 Leave Secure Cookies Alone] specification - ensure that newly created insecure cookies cannot override existing secure cookies (add tests to tests/unit/net/cookie.rs)

Current Structure 
[[File:Cookie_before.JPG]]
 
After Refactoring 
[[File:Cookie_after.JPG]]

The current implementation of CookieStorage utilizes vector of Cookies. No restrictions are placed on the number of cookies that can be added per host.The proposed change will refactor CookieStorage to use HashMap with Base host as key. There would a limit on the maximum number of cookies per host. Changes will also include, implementation of '''Deprecate modification of 'secure' cookies from non-secure origins''' which update RFC6265 by removing the ability for a non-secure origin to set cookies with a 'secure' flag, and to overwrite cookies whose 'secure' flag is set.

Since this contains refactoring, all existing unit testcases need to pass. Additionally, new unit test cases will be written for validating implementation of aforementioned specifi order for a cation.

In order for a non-secure cookie to not replace secure cookie, the following priority order is used while deciding to evict a cookie(s):

<ol>
<li> Expired cookies.
<li> Cookies whose "secure-only-flag" is not set and which share a "domain" field with more than a predetermined number of other cookies.
<li> Cookies that share a "domain" field with more than a predetermined number of other cookies.
<li> All cookies.
</ol>

=='''Approach'''==
First step would be to update the vector to HasMap by maintaining the wrapper functions used on the CookieStporage class. Upon completion of the task, all the unit test cases should pass. This would provide an additional checkpoint to verify the integrity of the new CookieStorage class's behavior.

Subsequent steps would include refactoring of the code so that the existing functionality is retained with added feature and advantages provided by HashMaps like faster search.

RFC implementation would be possible after the code refactor of CookieStorage class. Most of the RFC related changes are related to maintaining the content of the map. So this step would be penultimate step of the project.

Team would follow Test Driven Development, so unit tests would be written first wherever required and production code would be written to make the testcases pass.

We would follow Pair Programming to minimize errors and maximize the productivity. We are going to adhere to industry set standards which provide better QoS and stable product.

=='''Continuous Integration'''==
Continuous Integration, being a key element in Test Driven Development. Our team will setup our own Travis server to ensure code sanity.
==Test Plan==
There is no manual testing in this project. Existing unit tests will ensure that refactoring has not broken any functionality. New unit test cases would be written for validating "Leave Secure Cookies Alone" specification.

1) Unit test for checking "secure-only-flag" is set.
2) Unit test for "domain" domain-matches the "domain" of the newly created cookie, or vice-versa.
3) Unit test to validate The "path" of the newly created cookie path-matches the "path" of the existing cookie.

Please note that since lot of unit tests are already in place. We are not required to write many new test cases. After refactoring, if CI passes without any dip in code coverage then we can say refactoring is successful.
=='''Files modified'''==
* /servo/components/cookie_storage.rs
* /servo/components/net/cookie.rs
* /servo/test/unit/cookie.rs
* /servo/components/servo/cargo.toml
* /servo/components/servo/cargo.lock
* /servo/components/net/http_loader.rs
* /servo/components/net/resource_thread.rs

=='''Code Changes'''==
[[File:Cs1.jpg]]
 
In the images above, the changes reflect the code refactoring involved in changing linked list implementation to a HashMap implementation. Another important feature to notice is the addition of a new parameter for the Cookie Storage constructor. This value max_per_host dictates how many cookies per domain is supported by servo. For testing the value has been set to 5 and for production, the value has been set to 150 (as per Mozilla Team's guidelines).

=='''Key People'''==
=== Developers ===
* Guru Darshan
* Raghavendra Nayak
* Rishi Jain
* Tsung-Ying Chuang
=== Mentor ===
* Ed Gehringer

User:Rjain9

2016-12-11T21:46:20Z

Gpollep: /* Tasks */

M1654: Improve network security features for Servo (cookies and strict referrer policies)
 
=='''Introduction'''==
=== Servo ===
[https://servo.org/ Servo] is a modern high-performance browser engine designed for both application and embedded use which is written in Rust. It is created by Mozilla Research and is being built by a global community of individual contributors and companies such as Mozilla and Samsung.

Task Communication Diagram

[[File:Tasks1.jpg]]

=== HTTP Cookie ===
An [https://en.wikipedia.org/wiki/HTTP_cookie HTTP Cookie] is a small part of data which is sent by the website to the user's computer and is stored by the user's web browser while the user is browsing. A cookie is mainly used for recording a user's browsing activity or to remember stateful information for the websites.

=== Rust ===
[https://doc.rust-lang.org/book/ Rust] is a systems programming language developed and maintained by Mozilla. It is used as a multi-paradigm, compiled programming language for creating highly safe systems. Rust can be used for a variety of jobs including and not restricted to embedding into other languages, creating modular and optimized programs adhering to space-time constraints and can also be used to develop low-level code for writing device drivers.

=='''Project Description'''==
The goal of this project is to implement newer, more secure standards, and complete missing pieces of existing ones, in order to increase the security available to users of the Servo browser. The project entails adding improved network security features for Servo engine by implementing a maximum number of cookies per host, and restricting insecure cookies from overwriting secure ones. The initial steps for this project have been completed as part of the OSS Project.

=='''Tasks'''==

1) Compile Servo and ensure that it runs on tests/html/about-mozilla.html

2) Redesign CookieStorage to store cookies in a HashMap where the key is the base domain of the cookie's source (ie. "www.google.co.uk" becomes "google.co.uk")

3) Store a max_per_host limit in CookieStorage that is checked when adding new cookies; evict the oldest cookie if the limit is reached (add tests to tests/unit/net/cookie.rs)

4) Implement the [https://datatracker.ietf.org/doc/draft-ietf-httpbis-cookie-alone/?include_text=1 Leave Secure Cookies Alone] specification - ensure that newly created insecure cookies cannot override existing secure cookies (add tests to tests/unit/net/cookie.rs)

Current Structure 
[[File:Cookie_before.JPG]]
 
After Refactoring 
[[File:Cookie_after.JPG]]

The current implementation of CookieStorage utilizes vector of Cookies. No restrictions are placed on the number of cookies that can be added per host.The proposed change will refactor CookieStorage to use HashMap with Base host as key. There would a limit on the maximum number of cookies per host. Changes will also include, implementation of '''Deprecate modification of 'secure' cookies from non-secure origins''' which update RFC6265 by removing the ability for a non-secure origin to set cookies with a 'secure' flag, and to overwrite cookies whose 'secure' flag is set.

Since this contains refactoring, all existing unit testcases need to pass. Additionally, new unit test cases will be written for validating implementation of aforementioned specifi order for a cation.

In order for a non-secure cookie to not replace secure cookie, the following priority order is used while deciding to evict a cookie(s):

<ol>
<li> Expired cookies.
<li> Cookies whose "secure-only-flag" is not set and which share a "domain" field with more than a predetermined number of other cookies.
<li> Cookies that share a "domain" field with more than a predetermined number of other cookies.
<li> All cookies.
</ol>

[[File:Cs1.jpg]]
In the images above, the changes reflect the code refactoring involved in changing linked list implementation to a HashMap implementation. Another important feature to notice is the addition of a new parameter for the Cookie Storage constructor. This value max_per_host dictates how many cookies per domain is supported by servo. For testing the value has been set to 5 and for production, the value has been set to 150 (as per Mozilla Team's guidelines).

=='''Approach'''==
First step would be to update the vector to HasMap by maintaining the wrapper functions used on the CookieStporage class. Upon completion of the task, all the unit test cases should pass. This would provide an additional checkpoint to verify the integrity of the new CookieStorage class's behavior.

Subsequent steps would include refactoring of the code so that the existing functionality is retained with added feature and advantages provided by HashMaps like faster search.

RFC implementation would be possible after the code refactor of CookieStorage class. Most of the RFC related changes are related to maintaining the content of the map. So this step would be penultimate step of the project.

Team would follow Test Driven Development, so unit tests would be written first wherever required and production code would be written to make the testcases pass.

We would follow Pair Programming to minimize errors and maximize the productivity. We are going to adhere to industry set standards which provide better QoS and stable product.

=='''Continuous Integration'''==
Continuous Integration, being a key element in Test Driven Development. Our team will setup our own Travis server to ensure code sanity.
==Test Plan==
There is no manual testing in this project. Existing unit tests will ensure that refactoring has not broken any functionality. New unit test cases would be written for validating "Leave Secure Cookies Alone" specification.

1) Unit test for checking "secure-only-flag" is set.
2) Unit test for "domain" domain-matches the "domain" of the newly created cookie, or vice-versa.
3) Unit test to validate The "path" of the newly created cookie path-matches the "path" of the existing cookie.

Please note that since lot of unit tests are already in place. We are not required to write many new test cases. After refactoring, if CI passes without any dip in code coverage then we can say refactoring is successful.
=='''Files to be modified'''==
* /servo/components/cookie_storage.rs
* /servo/components/net/cookie.rs
* /servo/test/unit/cookie.rs
* /servo/components/servo/cargo.toml
* /servo/components/servo/cargo.lock

=='''Key People'''==
=== Developers ===
* Guru Darshan
* Raghavendra Nayak
* Rishi Jain
* Tsung-Ying Chuang
=== Mentor ===
* Ed Gehringer

User:Rjain9

2016-12-11T21:31:53Z

Gpollep: /* Tasks */

M1654: Improve network security features for Servo (cookies and strict referrer policies)
 
=='''Introduction'''==
=== Servo ===
[https://servo.org/ Servo] is a modern high-performance browser engine designed for both application and embedded use which is written in Rust. It is created by Mozilla Research and is being built by a global community of individual contributors and companies such as Mozilla and Samsung.

Task Communication Diagram

[[File:Tasks1.jpg]]

=== HTTP Cookie ===
An [https://en.wikipedia.org/wiki/HTTP_cookie HTTP Cookie] is a small part of data which is sent by the website to the user's computer and is stored by the user's web browser while the user is browsing. A cookie is mainly used for recording a user's browsing activity or to remember stateful information for the websites.

=== Rust ===
[https://doc.rust-lang.org/book/ Rust] is a systems programming language developed and maintained by Mozilla. It is used as a multi-paradigm, compiled programming language for creating highly safe systems. Rust can be used for a variety of jobs including and not restricted to embedding into other languages, creating modular and optimized programs adhering to space-time constraints and can also be used to develop low-level code for writing device drivers.

=='''Project Description'''==
The goal of this project is to implement newer, more secure standards, and complete missing pieces of existing ones, in order to increase the security available to users of the Servo browser. The project entails adding improved network security features for Servo engine by implementing a maximum number of cookies per host, and restricting insecure cookies from overwriting secure ones. The initial steps for this project have been completed as part of the OSS Project.

=='''Tasks'''==

1) Compile Servo and ensure that it runs on tests/html/about-mozilla.html

2) Redesign CookieStorage to store cookies in a HashMap where the key is the base domain of the cookie's source (ie. "www.google.co.uk" becomes "google.co.uk")

3) Store a max_per_host limit in CookieStorage that is checked when adding new cookies; evict the oldest cookie if the limit is reached (add tests to tests/unit/net/cookie.rs)

4) Implement the [https://datatracker.ietf.org/doc/draft-ietf-httpbis-cookie-alone/?include_text=1 Leave Secure Cookies Alone] specification - ensure that newly created insecure cookies cannot override existing secure cookies (add tests to tests/unit/net/cookie.rs)

Current Structure 
[[File:Cookie_before.JPG]]
 
After Refactoring 
[[File:Cookie_after.JPG]]

The current implementation of CookieStorage utilizes vector of Cookies. No restrictions are placed on the number of cookies that can be added per host.The proposed change will refactor CookieStorage to use HashMap with Base host as key. There would a limit on the maximum number of cookies per host. Changes will also include, implementation of '''Deprecate modification of 'secure' cookies from non-secure origins''' which update RFC6265 by removing the ability for a non-secure origin to set cookies with a 'secure' flag, and to overwrite cookies whose 'secure' flag is set.

Since this contains refactoring, all existing unit testcases need to pass. Additionally, new unit test cases will be written for validating implementation of aforementioned specifi order for a cation.

In order for a non-secure cookie to not replace secure cookie, the following priority order is used while deciding to evict a cookie(s):

<ol>
<li> Expired cookies.
<li> Cookies whose "secure-only-flag" is not set and which share a "domain" field with more than a predetermined number of other cookies.
<li> Cookies that share a "domain" field with more than a predetermined number of other cookies.
<li> All cookies.
</ol>

[[File:Cs1.jpg]]

=='''Approach'''==
First step would be to update the vector to HasMap by maintaining the wrapper functions used on the CookieStporage class. Upon completion of the task, all the unit test cases should pass. This would provide an additional checkpoint to verify the integrity of the new CookieStorage class's behavior.

Subsequent steps would include refactoring of the code so that the existing functionality is retained with added feature and advantages provided by HashMaps like faster search.

RFC implementation would be possible after the code refactor of CookieStorage class. Most of the RFC related changes are related to maintaining the content of the map. So this step would be penultimate step of the project.

Team would follow Test Driven Development, so unit tests would be written first wherever required and production code would be written to make the testcases pass.

We would follow Pair Programming to minimize errors and maximize the productivity. We are going to adhere to industry set standards which provide better QoS and stable product.

=='''Continuous Integration'''==
Continuous Integration, being a key element in Test Driven Development. Our team will setup our own Travis server to ensure code sanity.
==Test Plan==
There is no manual testing in this project. Existing unit tests will ensure that refactoring has not broken any functionality. New unit test cases would be written for validating "Leave Secure Cookies Alone" specification.

1) Unit test for checking "secure-only-flag" is set.
2) Unit test for "domain" domain-matches the "domain" of the newly created cookie, or vice-versa.
3) Unit test to validate The "path" of the newly created cookie path-matches the "path" of the existing cookie.

Please note that since lot of unit tests are already in place. We are not required to write many new test cases. After refactoring, if CI passes without any dip in code coverage then we can say refactoring is successful.
=='''Files to be modified'''==
* /servo/components/cookie_storage.rs
* /servo/components/net/cookie.rs
* /servo/test/unit/cookie.rs
* /servo/components/servo/cargo.toml
* /servo/components/servo/cargo.lock

=='''Key People'''==
=== Developers ===
* Guru Darshan
* Raghavendra Nayak
* Rishi Jain
* Tsung-Ying Chuang
=== Mentor ===
* Ed Gehringer

2016-11-16T02:18:04Z

Gpollep:

File:Cookie after.JPG

2016-11-16T02:17:38Z

Gpollep:

User:Rjain9

2016-11-16T01:55:27Z

Gpollep: /* Servo */

M1654: Improve network security features for Servo (cookies and strict referrer policies)
 
=='''Introduction'''==
=== Servo ===
[https://servo.org/ Servo] is a modern high-performance browser engine designed for both application and embedded use which is written in Rust. It is created by Mozilla Research and is being built by a global community of individual contributors and companies such as Mozilla and Samsung.

Task Communication Diagram

[[File:Tasks1.jpg]]

=== HTTP Cookie ===
An [https://en.wikipedia.org/wiki/HTTP_cookie HTTP Cookie] is a small part of data which is sent by the website to the user's computer and is stored by the user's web browser while the user is browsing. A cookie is mainly used for recording a user's browsing activity or to remember stateful information for the websites.

=== Rust ===
[https://doc.rust-lang.org/book/ Rust] is a systems programming language developed and maintained by Mozilla. It is used as a multi-paradigm, compiled programming language for creating highly safe systems. Rust can be used for a variety of jobs including and not restricted to embedding into other languages, creating modular and optimized programs adhering to space-time constraints and can also be used to develop low-level code for writing device drivers.

=='''Project Description'''==
The goal of this project is to implement newer, more secure standards, and complete missing pieces of existing ones, in order to increase the security available to users of the Servo browser. The project entails adding improved network security features for Servo engine by implementing a maximum number of cookies per host, and restricting insecure cookies from overwriting secure ones. The initial steps for this project have been completed as part of the OSS Project.

=='''Tasks'''==

1) Compile Servo and ensure that it runs on tests/html/about-mozilla.html

2) Redesign CookieStorage to store cookies in a HashMap where the key is the base domain of the cookie's source (ie. "www.google.co.uk" becomes "google.co.uk")

3) Store a max_per_host limit in CookieStorage that is checked when adding new cookies; evict the oldest cookie if the limit is reached (add tests to tests/unit/net/cookie.rs)

4) Implement the [https://datatracker.ietf.org/doc/draft-ietf-httpbis-cookie-alone/?include_text=1 Leave Secure Cookies Alone] specification - ensure that newly created insecure cookies cannot override existing secure cookies (add tests to tests/unit/net/cookie.rs)

The current implementation of CookieStorage utilizes vector of Cookies. No restrictions are placed on the number of cookies that can be added per host.The proposed change will refactor CookieStorage to use HashMap with Base host as key. There would a limit on the maximum number of cookies per host. Changes will also include, implementation of '''Deprecate modification of 'secure' cookies from non-secure origins''' which update RFC6265 by removing the ability for a non-secure origin to set cookies with a 'secure' flag, and to overwrite cookies whose 'secure' flag is set.

Since this contains refactoring, all existing unit testcases need to pass. Additionally, new unit test cases will be written for validating implementation of aforementioned specification.

=='''Approach'''==
First step would be to update the vector to HasMap by maintaining the wrapper functions used on the CookieStporage class. Upon completion of the task, all the unit test cases should pass. This would provide an additional checkpoint to verify the integrity of the new CookieStorage class's behavior.

Subsequent steps would include refactoring of the code so that the existing functionality is retained with added feature and advantages provided by HashMaps like faster search.

RFC implementation would be possible after the code refactor of CookieStorage class. Most of the RFC related changes are related to maintaining the content of the map. So this step would be penultimate step of the project.

Team would follow Test Driven Development, so unit tests would be written first wherever required and production code would be written to make the testcases pass.

We would follow Pair Programming to minimize errors and maximize the productivity. We are going to adhere to industry set standards which provide better QoS and stable product.

=='''Continuous Integration'''==
Continuous Integration, being a key element in Test Driven Development. Our team will setup our own Travis server to ensure code sanity.
==Test Plan==
There is no manual testing in this project. Existing unit tests will ensure that refactoring has not broken any functionality. New unit test cases would be written for validating "Leave Secure Cookies Alone" specification.

1) Unit test for checking "secure-only-flag" is set.
2) Unit test for "domain" domain-matches the "domain" of the newly created cookie, or vice-versa.
3) Unit test to validate The "path" of the newly created cookie path-matches the "path" of the existing cookie.

Please note that since lot of unit tests are already in place. We are not required to write many new test cases. After refactoring, if CI passes without any dip in code coverage then we can say refactoring is successful.
=='''Files to be modified'''==
* /servo/components/cookie_storage.rs
* /servo/components/net/cookie.rs
* /servo/test/unit/cookie.rs
* /servo/components/servo/cargo.toml
* /servo/components/servo/cargo.lock

=='''Key People'''==
=== Developers ===
* Guru Darshan
* Raghavendra Nayak
* Rishi Jain
* Tsung-Ying Chuang
=== Mentor ===
* Ed Gehringer

User:Rjain9

2016-11-16T01:54:14Z

CSC/ECE 517 Fall 2016/M1654. Improve network security features

2016-11-04T16:47:03Z

Gpollep: /* Implementation */

M1654: Improve network security features for Servo (cookies and strict referrer policies)
 

Servo supports standard [HTTP cookies] and parts of the Referral-Policy web standard. The project aims at increasing the security available to Servo browser users by implementing secure standards and complete the missing parts of the existing implementations. The project involves adding "strict" version of existing referrer policies.

=='''Introduction'''==

=== Rust ===
[https://doc.rust-lang.org/book/ Rust] is a systems programming language developed and maintained by Mozilla. It is used as a multi-paradigm, compiled programming language for creating highly safe systems. Rust can be used for a variety of jobs including and not restricted to embedding into other languages, creating modular and optimized programs adhering to space-time constraints and can also be used to develop low-level code for writing device drivers.

=== Servo ===
[https://servo.org/ Servo] is a modern high-performance browser engine designed for both application and embedded use which is written in Rust. It is created by Mozilla Research and is being built by a global community of individual contributors and companies such as Mozilla and Samsung.

=== Referrer Policy ===
Referrer is a HTTP header field which contains the source of the URL that requested the web page. Referrer-policy dictates algorithm used to generate Referrer header when a new web page is requested.

=='''Project Description'''==
The project entails adding improved network security features for Servo engine by supplementing the existing Referrer-policies with 'strict origin' and 'strict origin when cross origin' policies.

A brief description of the list of tasks assigned as part of the project is as follows:

1) Compile Servo and ensure that it runs on tests/html/about-mozilla.html

2) Email the mozilla.dev.servo mailing list (be sure to subscribe first!) introducing your group and asking any necessary questions

3) Implement strict-origin and strict-origin-when-cross-origin referrer policies (see determine_request_referrer and determine_policy_for_token)

4) Add support for the new strict policy values in the Referrer-Policy HTTP header (source)

5) Add tests for the new policy values in tests/unit/net/http_loader.rs (run with ./mach test-unit -p net)

=== Referrer Policies added in this project ===
==== Strict Origin ====
[https://w3c.github.io/webappsec-referrer-policy/#referrer-policy-strict-origin Strict Origin] Referrer Policy dictates that the Referrer in HTTP header is always filled with the stripped URL of the origin and not the complete URL.

==== Strict origin When Cross Origin ====
[https://w3c.github.io/webappsec-referrer-policy/#referrer-policy-strict-origin-when-cross-origin Strict Origin When Cross Origin] Referrer Policy dictates that the Referrer in HTTP header is filled with the stripped URL of the origin if the request is sent to a URL different from the origin and the complete URL is sent when making [https://en.wikipedia.org/wiki/Same-origin_policy same origin] requests.

== '''Design Pattern''' ==
No design patterns were used in this project.

== '''Implementation''' ==
Strict Origin and Strict Origin When Cross origin Referrer policy implementations have been added to the codebase. The pull request for Servo repository is available [https://github.com/servo/servo/pull/14059 here] and Hyper is available [https://github.com/hyperium/hyper/pull/943 here]

Referrer policy implementation 
[[File:Ubs.jpg]] 
Selected Test case changes 
[[File:Ubs1.jpg]]

For complete changes please refer aforementioned url.

All the newly implemented functions have been provided with URL corresponding to their documentation instead of a direct comment above the function. This is in accordance with the guidelines set by Mozilla for the Servo project. Hence no extra comments are added to the code. All the implementation details can be provided in the links provided above the functions.

== '''Testing''' ==
Various testcase scenerios involving request from HTTP to HTTPS URLs and vice-versa have been added in [https://github.com/servo/servo/pull/14059 tests/unit/net/http_loader.rs]. Full functionality coverage has been taken case of by ensuring that all same origin and cross origin test cases have been included.

No UI is available for testing the changes as the associated features involve cookies which do not have a visual interface. To test the changes follow these commands

<code>
./mach build --dev
./mach test-unit -p net
</code>

== '''Pull Request Details''' ==
Links to [https://github.com/rjain9/servo/pull/1 '''old'''] pull request and [https://github.com/servo/servo/pull/14059 '''new'''] pull request.

This '''new''' pull request contains commit implementing initial steps for Improving Network Security project. As part of initial steps referrer policy enums for strict-origin and strict-origin-when-cross-origin have been added to [https://github.com/hyperium/hyper/pull/943 hyper]. Unit tests and additional logic has been added to handle these policies. Since enum changes are available on hyper version 0.9.11. We had to update hyper version to 0.9.11.

Hyper 0.9.11 depends on num_cpus 1.1.0. To avoid a different version of num_cpus. We have updated rayon version from 0.4.0 to 0.4.3. Cargo.toml of util, style, geckolib, stylo component has been updated to use num_cpus version 1.1.0 instead of 0.2.2.

Mozilla guidelines suggest that multiple concise commits should be wrapped into a single commit. Hence the '''old''' request shows the individual contributions but the '''new''' pull request contains only one major commit (and review comments based commits).

== '''Commit Frequency''' ==
Since this is a Mozilla project, all the changes were submitted in a single commit.

CSC/ECE 517 Fall 2016/M1654. Improve network security features

2016-11-04T16:45:38Z

Gpollep: /* Implementation */

M1654: Improve network security features for Servo (cookies and strict referrer policies)
 

Servo supports standard [HTTP cookies] and parts of the Referral-Policy web standard. The project aims at increasing the security available to Servo browser users by implementing secure standards and complete the missing parts of the existing implementations. The project involves adding "strict" version of existing referrer policies.

=='''Introduction'''==

=== Rust ===
[https://doc.rust-lang.org/book/ Rust] is a systems programming language developed and maintained by Mozilla. It is used as a multi-paradigm, compiled programming language for creating highly safe systems. Rust can be used for a variety of jobs including and not restricted to embedding into other languages, creating modular and optimized programs adhering to space-time constraints and can also be used to develop low-level code for writing device drivers.

=== Servo ===
[https://servo.org/ Servo] is a modern high-performance browser engine designed for both application and embedded use which is written in Rust. It is created by Mozilla Research and is being built by a global community of individual contributors and companies such as Mozilla and Samsung.

=== Referrer Policy ===
Referrer is a HTTP header field which contains the source of the URL that requested the web page. Referrer-policy dictates algorithm used to generate Referrer header when a new web page is requested.

=='''Project Description'''==
The project entails adding improved network security features for Servo engine by supplementing the existing Referrer-policies with 'strict origin' and 'strict origin when cross origin' policies.

A brief description of the list of tasks assigned as part of the project is as follows:

1) Compile Servo and ensure that it runs on tests/html/about-mozilla.html

2) Email the mozilla.dev.servo mailing list (be sure to subscribe first!) introducing your group and asking any necessary questions

3) Implement strict-origin and strict-origin-when-cross-origin referrer policies (see determine_request_referrer and determine_policy_for_token)

4) Add support for the new strict policy values in the Referrer-Policy HTTP header (source)

5) Add tests for the new policy values in tests/unit/net/http_loader.rs (run with ./mach test-unit -p net)

=== Referrer Policies added in this project ===
==== Strict Origin ====
[https://w3c.github.io/webappsec-referrer-policy/#referrer-policy-strict-origin Strict Origin] Referrer Policy dictates that the Referrer in HTTP header is always filled with the stripped URL of the origin and not the complete URL.

==== Strict origin When Cross Origin ====
[https://w3c.github.io/webappsec-referrer-policy/#referrer-policy-strict-origin-when-cross-origin Strict Origin When Cross Origin] Referrer Policy dictates that the Referrer in HTTP header is filled with the stripped URL of the origin if the request is sent to a URL different from the origin and the complete URL is sent when making [https://en.wikipedia.org/wiki/Same-origin_policy same origin] requests.

== '''Design Pattern''' ==
No design patterns were used in this project.

== '''Implementation''' ==
Strict Origin and Strict Origin When Cross origin Referrer policy implementations have been added to the codebase. The pull request for Servo repository is available [https://github.com/servo/servo/pull/14059 here] and Hyper is available [https://github.com/hyperium/hyper/pull/943 here]

Referrer policy implementation 
[[File:Ubs.jpg]] 
Selected Test case changes 
[[File:Ubs1.jpg]]

For complete changes please refer aforementioned url.

All the newly implemented functions have been provided with URL corresponding to their documentation instead of a direct comment above the function. This is in accordance with the guidelines set by Mozilla for the Servo project. So no extra comments are added to the code. All the implementation details can be provided in the links provided above the functions.

== '''Testing''' ==
Various testcase scenerios involving request from HTTP to HTTPS URLs and vice-versa have been added in [https://github.com/servo/servo/pull/14059 tests/unit/net/http_loader.rs]. Full functionality coverage has been taken case of by ensuring that all same origin and cross origin test cases have been included.

No UI is available for testing the changes as the associated features involve cookies which do not have a visual interface. To test the changes follow these commands

<code>
./mach build --dev
./mach test-unit -p net
</code>

== '''Pull Request Details''' ==
Links to [https://github.com/rjain9/servo/pull/1 '''old'''] pull request and [https://github.com/servo/servo/pull/14059 '''new'''] pull request.

This '''new''' pull request contains commit implementing initial steps for Improving Network Security project. As part of initial steps referrer policy enums for strict-origin and strict-origin-when-cross-origin have been added to [https://github.com/hyperium/hyper/pull/943 hyper]. Unit tests and additional logic has been added to handle these policies. Since enum changes are available on hyper version 0.9.11. We had to update hyper version to 0.9.11.

Hyper 0.9.11 depends on num_cpus 1.1.0. To avoid a different version of num_cpus. We have updated rayon version from 0.4.0 to 0.4.3. Cargo.toml of util, style, geckolib, stylo component has been updated to use num_cpus version 1.1.0 instead of 0.2.2.

Mozilla guidelines suggest that multiple concise commits should be wrapped into a single commit. Hence the '''old''' request shows the individual contributions but the '''new''' pull request contains only one major commit (and review comments based commits).

== '''Commit Frequency''' ==
Since this is a Mozilla project, all the changes were submitted in a single commit.

CSC/ECE 517 Fall 2016/M1654. Improve network security features

2016-11-04T16:42:37Z

Gpollep: /* Pull Request Details */

M1654: Improve network security features for Servo (cookies and strict referrer policies)
 

Servo supports standard [HTTP cookies] and parts of the Referral-Policy web standard. The project aims at increasing the security available to Servo browser users by implementing secure standards and complete the missing parts of the existing implementations. The project involves adding "strict" version of existing referrer policies.

=='''Introduction'''==

=== Rust ===
[https://doc.rust-lang.org/book/ Rust] is a systems programming language developed and maintained by Mozilla. It is used as a multi-paradigm, compiled programming language for creating highly safe systems. Rust can be used for a variety of jobs including and not restricted to embedding into other languages, creating modular and optimized programs adhering to space-time constraints and can also be used to develop low-level code for writing device drivers.

=== Servo ===
[https://servo.org/ Servo] is a modern high-performance browser engine designed for both application and embedded use which is written in Rust. It is created by Mozilla Research and is being built by a global community of individual contributors and companies such as Mozilla and Samsung.

=== Referrer Policy ===
Referrer is a HTTP header field which contains the source of the URL that requested the web page. Referrer-policy dictates algorithm used to generate Referrer header when a new web page is requested.

=='''Project Description'''==
The project entails adding improved network security features for Servo engine by supplementing the existing Referrer-policies with 'strict origin' and 'strict origin when cross origin' policies.

A brief description of the list of tasks assigned as part of the project is as follows:

1) Compile Servo and ensure that it runs on tests/html/about-mozilla.html

2) Email the mozilla.dev.servo mailing list (be sure to subscribe first!) introducing your group and asking any necessary questions

3) Implement strict-origin and strict-origin-when-cross-origin referrer policies (see determine_request_referrer and determine_policy_for_token)

4) Add support for the new strict policy values in the Referrer-Policy HTTP header (source)

5) Add tests for the new policy values in tests/unit/net/http_loader.rs (run with ./mach test-unit -p net)

=== Referrer Policies added in this project ===
==== Strict Origin ====
[https://w3c.github.io/webappsec-referrer-policy/#referrer-policy-strict-origin Strict Origin] Referrer Policy dictates that the Referrer in HTTP header is always filled with the stripped URL of the origin and not the complete URL.

==== Strict origin When Cross Origin ====
[https://w3c.github.io/webappsec-referrer-policy/#referrer-policy-strict-origin-when-cross-origin Strict Origin When Cross Origin] Referrer Policy dictates that the Referrer in HTTP header is filled with the stripped URL of the origin if the request is sent to a URL different from the origin and the complete URL is sent when making [https://en.wikipedia.org/wiki/Same-origin_policy same origin] requests.

== '''Design Pattern''' ==
No design patterns were used in this project.

== '''Implementation''' ==
Strict Origin and Strict Origin When Cross origin Referrer policy implementations have been added to the codebase. The pull request for Servo repository is available [https://github.com/servo/servo/pull/14059 here] and Hyper is available [https://github.com/hyperium/hyper/pull/943 here]

Referrer policy implementation 
[[File:Ubs.jpg]] 
Selected Test case changes 
[[File:Ubs1.jpg]]

For complete changes please refer aforementioned url.

== '''Testing''' ==
Various testcase scenerios involving request from HTTP to HTTPS URLs and vice-versa have been added in [https://github.com/servo/servo/pull/14059 tests/unit/net/http_loader.rs]. Full functionality coverage has been taken case of by ensuring that all same origin and cross origin test cases have been included.

No UI is available for testing the changes as the associated features involve cookies which do not have a visual interface. To test the changes follow these commands

<code>
./mach build --dev
./mach test-unit -p net
</code>

== '''Pull Request Details''' ==
Links to [https://github.com/rjain9/servo/pull/1 '''old'''] pull request and [https://github.com/servo/servo/pull/14059 '''new'''] pull request.

This '''new''' pull request contains commit implementing initial steps for Improving Network Security project. As part of initial steps referrer policy enums for strict-origin and strict-origin-when-cross-origin have been added to [https://github.com/hyperium/hyper/pull/943 hyper]. Unit tests and additional logic has been added to handle these policies. Since enum changes are available on hyper version 0.9.11. We had to update hyper version to 0.9.11.

Hyper 0.9.11 depends on num_cpus 1.1.0. To avoid a different version of num_cpus. We have updated rayon version from 0.4.0 to 0.4.3. Cargo.toml of util, style, geckolib, stylo component has been updated to use num_cpus version 1.1.0 instead of 0.2.2.

Mozilla guidelines suggest that multiple concise commits should be wrapped into a single commit. Hence the '''old''' request shows the individual contributions but the '''new''' pull request contains only one major commit (and review comments based commits).

== '''Commit Frequency''' ==
Since this is a Mozilla project, all the changes were submitted in a single commit.

CSC/ECE 517 Fall 2016/M1654. Improve network security features

2016-11-04T16:30:12Z

Gpollep: Added testing commands

M1654: Improve network security features for Servo (cookies and strict referrer policies)
 

Servo supports standard [HTTP cookies] and parts of the Referral-Policy web standard. The project aims at increasing the security available to Servo browser users by implementing secure standards and complete the missing parts of the existing implementations. The project involves adding "strict" version of existing referrer policies.

=='''Introduction'''==

=== Rust ===
[https://doc.rust-lang.org/book/ Rust] is a systems programming language developed and maintained by Mozilla. It is used as a multi-paradigm, compiled programming language for creating highly safe systems. Rust can be used for a variety of jobs including and not restricted to embedding into other languages, creating modular and optimized programs adhering to space-time constraints and can also be used to develop low-level code for writing device drivers.

=== Servo ===
[https://servo.org/ Servo] is a modern high-performance browser engine designed for both application and embedded use which is written in Rust. It is created by Mozilla Research and is being built by a global community of individual contributors and companies such as Mozilla and Samsung.

=== Referrer Policy ===
Referrer is a HTTP header field which contains the source of the URL that requested the web page. Referrer-policy dictates algorithm used to generate Referrer header when a new web page is requested.

=='''Project Description'''==
The project entails adding improved network security features for Servo engine by supplementing the existing Referrer-policies with 'strict origin' and 'strict origin when cross origin' policies.

A brief description of the list of tasks assigned as part of the project is as follows:

1) Compile Servo and ensure that it runs on tests/html/about-mozilla.html

2) Email the mozilla.dev.servo mailing list (be sure to subscribe first!) introducing your group and asking any necessary questions

3) Implement strict-origin and strict-origin-when-cross-origin referrer policies (see determine_request_referrer and determine_policy_for_token)

4) Add support for the new strict policy values in the Referrer-Policy HTTP header (source)

5) Add tests for the new policy values in tests/unit/net/http_loader.rs (run with ./mach test-unit -p net)

=== Referrer Policies added in this project ===
==== Strict Origin ====
[https://w3c.github.io/webappsec-referrer-policy/#referrer-policy-strict-origin Strict Origin] Referrer Policy dictates that the Referrer in HTTP header is always filled with the stripped URL of the origin and not the complete URL.

==== Strict origin When Cross Origin ====
[https://w3c.github.io/webappsec-referrer-policy/#referrer-policy-strict-origin-when-cross-origin Strict Origin When Cross Origin] Referrer Policy dictates that the Referrer in HTTP header is filled with the stripped URL of the origin if the request is sent to a URL different from the origin and the complete URL is sent when making [https://en.wikipedia.org/wiki/Same-origin_policy same origin] requests.

== '''Design Pattern''' ==
No design patterns were used in this project.

== '''Implementation''' ==
Strict Origin and Strict Origin When Cross origin Referrer policy implementations have been added to the codebase. The pull request for Servo repository is available [https://github.com/servo/servo/pull/14059 here] and Hyper is available [https://github.com/hyperium/hyper/pull/943 here]

Referrer policy implementation 
[[File:Ubs.jpg]] 
Selected Test case changes 
[[File:Ubs1.jpg]]

For complete changes please refer aforementioned url.

== '''Testing''' ==
Various testcase scenerios involving request from HTTP to HTTPS URLs and vice-versa have been added in [https://github.com/servo/servo/pull/14059 tests/unit/net/http_loader.rs]. Full functionality coverage has been taken case of by ensuring that all same origin and cross origin test cases have been included.

No UI is available for testing the changes as the associated features involve cookies which do not have a visual interface. To test the changes follow these commands

<code>
./mach build --dev
./mach test-unit -p net
</code>

== '''Pull Request Details''' ==
This pull request contains commit implementing initial steps for Improving Network Security project. As part of initial steps referrer policy enums for strict-origin and strict-origin-when-cross-origin have been added to hyper([https://github.com/hyperium/hyper/pull/943]). Unit tests and additional logic has been added to handle these policies. Since enum changes are available on hyper version 0.9.11. We had to update hyper version to 0.9.11.

Hyper 0.9.11 depends on num_cpus 1.1.0. To avoid a different version of num_cpus. We have updated rayon version from 0.4.0 to 0.4.3. Cargo.toml of util, style, geckolib, stylo component has been updated to use num_cpus version 1.1.0 instead of 0.2.2.

== '''Commit Frequency''' ==
Since this is a Mozilla project, all the changes were submitted in a single commit.

CSC/ECE 517 Fall 2016/M1654. Improve network security features

2016-11-04T16:21:29Z

Gpollep: Added pull request details

M1654: Improve network security features for Servo (cookies and strict referrer policies)
 

Servo supports standard [HTTP cookies] and parts of the Referral-Policy web standard. The project aims at increasing the security available to Servo browser users by implementing secure standards and complete the missing parts of the existing implementations. The project involves adding "strict" version of existing referrer policies.

=='''Introduction'''==

=== Rust ===
[https://doc.rust-lang.org/book/ Rust] is a systems programming language developed and maintained by Mozilla. It is used as a multi-paradigm, compiled programming language for creating highly safe systems. Rust can be used for a variety of jobs including and not restricted to embedding into other languages, creating modular and optimized programs adhering to space-time constraints and can also be used to develop low-level code for writing device drivers.

=== Servo ===
[https://servo.org/ Servo] is a modern high-performance browser engine designed for both application and embedded use which is written in Rust. It is created by Mozilla Research and is being built by a global community of individual contributors and companies such as Mozilla and Samsung.

=== Referrer Policy ===
Referrer is a HTTP header field which contains the source of the URL that requested the web page. Referrer-policy dictates algorithm used to generate Referrer header when a new web page is requested.

=='''Project Description'''==
The project entails adding improved network security features for Servo engine by supplementing the existing Referrer-policies with 'strict origin' and 'strict origin when cross origin' policies.

A brief description of the list of tasks assigned as part of the project is as follows:

1) Compile Servo and ensure that it runs on tests/html/about-mozilla.html

2) Email the mozilla.dev.servo mailing list (be sure to subscribe first!) introducing your group and asking any necessary questions

3) Implement strict-origin and strict-origin-when-cross-origin referrer policies (see determine_request_referrer and determine_policy_for_token)

4) Add support for the new strict policy values in the Referrer-Policy HTTP header (source)

5) Add tests for the new policy values in tests/unit/net/http_loader.rs (run with ./mach test-unit -p net)

=== Referrer Policies added in this project ===
==== Strict Origin ====
[https://w3c.github.io/webappsec-referrer-policy/#referrer-policy-strict-origin Strict Origin] Referrer Policy dictates that the Referrer in HTTP header is always filled with the stripped URL of the origin and not the complete URL.

==== Strict origin When Cross Origin ====
[https://w3c.github.io/webappsec-referrer-policy/#referrer-policy-strict-origin-when-cross-origin Strict Origin When Cross Origin] Referrer Policy dictates that the Referrer in HTTP header is filled with the stripped URL of the origin if the request is sent to a URL different from the origin and the complete URL is sent when making [https://en.wikipedia.org/wiki/Same-origin_policy same origin] requests.

== '''Design Pattern''' ==
No design patterns were used in this project.

== '''Implementation''' ==
Strict Origin and Strict Origin When Cross origin Referrer policy implementations have been added to the codebase. The pull request for Servo repository is available [https://github.com/servo/servo/pull/14059 here] and Hyper is available [https://github.com/hyperium/hyper/pull/943 here]

Referrer policy implementation 
[[File:Ubs.jpg]] 
Selected Test case changes 
[[File:Ubs1.jpg]]

For complete changes please refer aforementioned url.

== '''Testing''' ==
Various testcase scenerios involving request from HTTP to HTTPS URLs and vice-versa have been added in [https://github.com/servo/servo/pull/14059 tests/unit/net/http_loader.rs]. Full functionality coverage has been taken case of by ensuring that all same origin and cross origin test cases have been included.

== '''Pull Request Details''' ==
This pull request contains commit implementing initial steps for Improving Network Security project. As part of initial steps referer policy enums for strict-origin and strict-origin-when-cross-origin have been added to hyper([https://github.com/hyperium/hyper/pull/943]). Unit tests and additional logic has been added to handle these policies. Since enum changes are available on hyper version 0.9.11. We had to update hyper version to 0.9.11.

Hyper 0.9.11 depends on num_cpus 1.1.0. To avoid different version of num_cpus. We have updated rayon version from 0.4.0 to 0.4.3. Cargo.toml of util, style, geckolib, stylo component has been updated to use num_cpus version 1.1.0 instead of 0.2.2.

== '''Commit Frequency''' ==
Since this is a Mozilla project, all the changes were submitted in a single commit.

CSC/ECE 517 Fall 2016/M1654. Improve network security features

2016-11-04T16:20:05Z

Gpollep: Updated links

CSC/ECE 517 Fall 2016/M1654. Improve network security features

2016-11-04T01:37:53Z

Gpollep: Added commit freq

CSC/ECE 517 Fall 2016/M1654. Improve network security features

2016-11-04T01:29:35Z

Gpollep: Added Design pattern

CSC/ECE 517 Fall 2016/M1654. Improve network security features

2016-10-28T21:56:59Z

Gpollep: /* Testing */

CSC/ECE 517 Fall 2016/M1654. Improve network security features

2016-10-28T21:52:24Z

Gpollep: Added Project steps