Categories
Deploy360 Events IETF IPv6 Open Internet Standards Securing Border Gateway Protocol (BGP)

IETF 102, Day 5: Au revoir Montréal

There’s just the couple of sessions to highlight on the last day of IETF 102 before we wrap up for the week.

V6OPS continues at 09.30 EDT/UTC-4 where it left off on Thursday afternoon. On the agenda are drafts relating to Multi-Addressing Considerations for IPv6 Prefix Delegation which considers prefix delegation considerations for both classic routing and various multi-addressing use cases; whilst IP over Ethernet (IPoE) Session Health Checking describes a mechanism for IP over Ethernet clients to achieve connectivity validation using PPP-style keepalives such as BFD Echo, or ARP and Neighbor Discovery functions.

The remaining draft proposes a method for Discovering Provisioning Domain Names and Data, which describes a way for hosts accessing the Internet via multiple interfaces and with possible multiple IPv6 prefixes, to identify themselves using Fully Qualified Domains as Provisioning Domain identifiers.


NOTE: If you are unable to attend IETF 102 in person, there are multiple ways to participate remotely.


The final session starting 11.50 EDT/UTC-4 includes IDR. This has been working on (amongst other things) the issue of route leaks, and is trying to pull together different conflicting approaches towards mitigation of these in favour of a more complementary approach. This work includes two drafts on Methods for Detection and Mitigation of BGP Route Leaks, and on Design Discussion of Route Leaks Solution Methods.

With that, IETF 102 draws to a close and we say au revoir to Montréal. Many thanks for reading along this week… please do read our other IETF 102-related posts … and we’ll see you at IETF 103 on 3-9 November 2018 which for the first time is being held in Bangkok, Thailand!

Relevant Working Groups

Categories
Deploy360 Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) Events IETF Internet of Things (IoT) IPv6 Open Internet Standards Transport Layer Security (TLS)

IETF 102, Day 4: DNS, IoT & TLS

This week is IETF 102 in Montreal, Canada, and we’re bringing you daily blog posts highlighting the topics of interest to us in the ISOC Internet Technology Team. Today we’re focusing on DNS, IoT and TLS issues.

LPWAN is the first event of the day starting at 09.30 EDT/UTC-4. There will be a discussion relating to the Working Group Last Call on the Static Context Header Compression (SCHC) framework, which provides both header compression and fragmentation functionalities; and on how to advance the LPWAN Static Context Header Compression (SCHC) for CoAP specification. Two other drafts are being presented for adoption by the Working Group relating to SCHC specifications (see https://tools.ietf.org/html/draft-petrov-lpwan-ipv6-schc-over-lorawan-02 and https://tools.ietf.org/html/draft-zuniga-lpwan-schc-over-sigfox-03).


NOTE: If you are unable to attend IETF 102 in person, there are multiple ways to participate remotely.


The first session of V6OPS commences at 13.30 EDT/UTC-4, and will continue on Friday morning. Today’s agenda items include a presentation on World IPv6 Trends from APNIC Labs, followed by discussion on a new draft NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks which describes considerations with respect to applications or devices using literal IPv4 addresses or non-IPv6 compliant APIs, as well as IPv4-only hosts on an IPv6-only network. Two existing drafts will also be discussed – Requirements for IPv6 Routers that defines a set of recommendations for routers, switches, and middleboxes deployed in IPv6 networks; and Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity as-a-Service which extends RFC 7084 in order to allow the provisioning of IPv6 transition services for the support of IPv4 as a Service (IPv4aaS).

During the second part of the afternoon starting at 15.50 EDT/UTC-4, there’s a choice of two meetings.

DNS Resolver Identification and Use (DRIU) is a BoF to discuss how to identify DNS stub resolvers that support privacy (i.e. DNS-over-TLS and DNS-over-HTTPS) using DHCP and DHCPv6. There’s a couple of drafts under discussion on DHCPv6 Options for private DNS Discovery, and DOH digests that provides a mechanism for selecting a DNS-over-HTTPS (DOH) server.

Alternatively, you can choose T2TRG that will consider the report from the Workshop on IoT Semantic/Hypermedia Interoperability (WISHI), along with an update on the iot.schema.org that enables webmasters to embed structured data on their web pages for use by search engines and other applications. Following this will be a discussion on the next steps for IoT security, including a draft that reviews the state-of-the-art and the challenges for IoT security. A further draft offers guidance for designing Internet of Things (IoT) systems that follow the REST architectural style.

Then for the evening session starting at 18.10 EDT/UTC-4, there’s again the choice of two meetings:

TLS continues on from Monday afternoon, and will consider three drafts during this session. Certificate-based Authentication with External PSK specifies a TLS 1.3 extension that allows a server to authenticate with a combination of a certificate and an external pre-shared key (PSK); Ticket Requests describes a mechanism by which clients may request tickets as needed during a connection, in order to address a limitation on the number of parallel connection a client may initiate; whilst Encrypted Server Name Indication (ESNI) defines a simpler mechanism to conceal the domain name a client is trying to connect to.

DNSOP also continues from where it left off on Wednesday morning. A couple of interesting drafts that may come up in this session include a DNS proxy use case to tunnel DNS query and response using DNS over HTTPs (DOH) protocol; and a proposed protocol and DNS Resource Record to compute, sign, represent, and use a message digest to verify the contents of a DNS zone.

For more background, please read the Rough Guide to IETF 102 from Olaf, Dan, Andrei, Steve, Karen and myself.

Relevant Working Groups

Categories
Deploy360 Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) Events IETF Internet of Things (IoT) IPv6 Open Internet Standards

IETF 102, Day 3: DNSSEC, DPRIVE & IoT

This week is IETF 102 in Montreal, Canada, and we’re bringing you daily blog posts highlighting the topics of interest to us in the ISOC Internet Technology Team. And today’s topics include DNS Security & Privacy, along with more IPv6 and IoT.

The first DNSOP session will start at 09.30 EDT/UTC-4, and will continue on Thursday evening. Topics of interest include a draft on Algorithm Implementation Requirements and Usage Guidance for DNSSEC, which updates current algorithm implementation requirements and usage guidance for DNSSEC (obsoleting RFC 6944). Another draft on Multi Provider DNSSEC models describes how to deploy DNSSEC in environments where multiple DNS providers are in use, whilst Delegation_Only DNSKEY flag introduces a new flag for DNSSEC keys that can address a potential attack.


NOTE: If you are unable to attend IETF 102 in person, there are multiple ways to participate remotely.


Alternatively, the relatively new working group SUIT will also be meeting at the same time. Vulnerabilities in Internet of Things (IoT) devices have raised the need for secure firmware updates that are also suitable for a constrained environments, and this group aims to develop an interoperable update mechanism. There are three drafts up for discussion, including the description of the firmware update architecture, a specification for the firmware update metadata model or manifest, as well a specification for the firmware manifest format. The next steps will also be discussed.

In the first afternoon session starting at 13.30 EDT/UTC-4, there’s a choice of DPRIVE or 6TiSCH.

DPRIVE will kick off with an analysis of RIPE Atlas probe data relating to DNS Privacy, before discussing some recommendations for DNS Privacy Service Operators. There’s also some new work on Oblivious DNS that introduces an additional layer of obfuscation between clients and their queries, and there will be some discussion about how to add privacy to the communication between recursive resolvers and authoritative DNS servers. The latter is beyond the scope of the current Working Group charter and so the group will consider whether to ask to expand their mandate.

6TiSCH has a busy agenda with the 6top protocol that enables distributed scheduling being targeted for an IETF Last Call, whilst the IESG feedback on the security functionality will be discussed. Two other drafts are aiming for Working Group adoption including a description of a scheduling function that defines the behavior of a node when joining a network and a mechanism for carrying important information in infrequent network broadcasts. Another new draft defines a secure joining mechanism for enrolling devices into an 802.15.4 TSG network using 6TiSCH signalling methods.

In the second afternoon session starting at 15.20 EDT/UTC-4, Homenet will continue to discuss the Homenet profile of the Babel routing protocol. There are also two updated drafts on the agenda, relating to third party provisioning of naming services for home networks and defining DHCPv6 options so that naming services can be outsourced.

Rounding off the day is the IETF Plenary starting at 17.10 EDT/UTC-4.

For more background, please read the Rough Guide to IETF 102 from Olaf, Dan, Andrei, Steve, Karen and myself.

Relevant Working Groups

Categories
Community Networks Deploy360 Encryption Events IETF Internet of Things (IoT) IPv6 Open Internet Standards

IETF 102, Day 2: Trust in the IETF

This week is IETF 102 in Montreal, Canada, and we’re bringing you daily blog posts highlighting the topics of interest to us in the ISOC Internet Technology Team. And today’s topics include IPv6, IoT and Trust technologies.

6MAN commences at 09.30 EDT/UTC-4, and has six new drafts up for discussion covering IPv6 Neighbor Discovery Extensions for Prefix Delegation, IPv6 VPNs, ICMPv6, OAM in Segment Routing Networks with an IPv6 Data plane, allowing low or zero valid lifetimes to be accepted in Router Advertisement Prefix Information Options where it’s known that there can only be one router on the link; as well as introducing a new IPv6 ‘unrecognised’ option for ICMPv6 that conveys whether an underlying network can transmit IPv6 packets.

There are also three working group sponsored drafts, adopted from the last meeting. Privacy Extensions for Stateless Address Autoconfiguration in IPv6 describes an extension that causes nodes to generate global scope addresses from interface identifiers that change over time; IPv6 Segment Routing Header specifies how a node can steer a packet through a controlled set of instructions (segments) by prepending an SR header to the packet; whilst IPv6 Router Advertisement IPv6-Only Flag is an update to RFC 5175 that indicates to hosts that a link is IPv6-only.


NOTE: If you are unable to attend IETF 102 in person, there are multiple ways to participate remotely.


There’s a choice of two meetings starting first thing at 09.30 EDT/UTC-4:

DMM is working on solutions for IP networks so that traffic between mobile devices and and correspondent nodes can take an optimal route. And there are several IPv6-related drafts including a couple related to Segment Routing (SRv6) for the Mobile User Plane (see https://www.ietf.org/id/draft-camarillo-dmm-srv6-mobile-pocs.txt and https://www.ietf.org/id/draft-ietf-dmm-srv6-mobile-uplane-02.txt), as well as on Proxy Mobile IPv6 extensions for Distributed Mobility Management. There’s also three drafts on 5G implementations which might be interesting.

Over in ROLL, they’ll be discussing an applicability statement for battery-powered remote metering devices and two others relating to routing headers and multicast parameters. There’s also a new draft on route discovery for symmetric and asymmetric Point-to-Point traffic flows.

Straight after lunch at 13.30-15.30 EDT/UTC-4 is 6LO , that’s preparing the IPv6 Backbone Router draft for a Working Group Last Call. There will also be an update regarding IESG review of the proposed revisions of RFCs 6550 and 6775 where 6LoWPAN Neighbor Discovery nodes in an RPL domain do not participate in the routing protocol, and a review of security considerations for Address Protected Neighbor Discovery that protects the owner of an address against address theft and impersonation inside a low-power and lossy network. Other drafts up for discussion include Design Considerations for Low-Power Networks to provide guidelines for improving interoperability, IPv6 over Power-Line Communication Networks, and on enabling IPv6 mesh networks over Bluetooth.

During the evening session commencing at 17.20 EDT/UCT-4, there’s another choice to be made between ACME and CFRG.

ACME is primarily focusing on agreeing the Automatic Certificate Management Environment protocol that is used to automate the process of verification, certificate issuance and revocation, and will be looking for consensus on a Working Group Last Call. Also up for discussion though, is the ACME TLS ALPN extension that allows for domain control validation using TLS, and Support for Short-Term, Automatically-Renewed (STAR) Certificates.

CFRG has five drafts on the agenda including randomness improvements for security protocols which is critical to the robustness of TLS and other security related cryptography; and Verifiable Random Functions (VRFs) which offer provide privacy against offline enumeration on data stored in a hash-based
data structure. Somewhat related is a draft that specifies a number of algorithms that may be used to hash arbitrary strings to Elliptic Curves, and another specifying a hash function with arbitrary output length.

Finally, although it’s not normally one of the Rough Guide topics, we’d like to highlight that the Global Access to the Internet for All (GAIA) Research Group will be holding a meeting at 15.50 EDT/UTC-4. This is chaired by our colleague Jane Coffin and aims to raise awareness and discuss the challenges and opportunities of enabling global Internet access. In particular to document and share deployment experiences and research results with the wider community, and to analyse how the costs of providing Internet access can be reduced for areas with low penetration.

For more background, please read the Rough Guide to IETF 102 from Olaf, Dan, Andrei, Steve, Karen and myself.

Relevant Working Groups

Categories
Deploy360 Events IETF Improving Technical Security Internet of Things (IoT) IPv6 Open Internet Standards Securing Border Gateway Protocol (BGP) Transport Layer Security (TLS)

IETF 102, Day 1: IETF arrive à Montréal

Tomorrow sees kickoff of the Working Groups sessions at IETF 102 in Montreal, Canada, we’re bringing you daily blog posts highlighting the topics of interest to us in the ISOC Internet Technology Team. Monday is an important day, with meetings of the TLS, 6MAN and SIDROPS Working Groups, along with two other IoT related groups.

6MAN commences at 09.30 EDT/UTC-4, and has six new drafts up for discussion covering IPv6 Neighbor Discovery Extensions for Prefix Delegation, IPv6 VPNs, ICMPv6, OAM in Segment Routing Networks with an IPv6 Data plane, allowing low or zero valid lifetimes to be accepted in Router Advertisement Prefix Information Options where it’s known that there can only be one router on the link; as well as introducing a new IPv6 ‘unrecognised’ option for ICMPv6 that conveys whether an underlying network can transmit IPv6 packets.

There are also three working group sponsored drafts, adopted from the last meeting. Privacy Extensions for Stateless Address Autoconfiguration in IPv6 describes an extension that causes nodes to generate global scope addresses from interface identifiers that change over time; IPv6 Segment Routing Header specifies how a node can steer a packet through a controlled set of instructions (segments) by prepending an SR header to the packet; whilst IPv6 Router Advertisement IPv6-Only Flag is an update to RFC 5175 that indicates to hosts that a link is IPv6-only.


NOTE: If you are unable to attend IETF 102 in person, there are multiple ways to participate remotely.


ACE is running parallel with 6MAN, and will be discussing various drafts related to using DTLSOAuth, and Object Security in RESTful Environments and Proof of Possession for Web Tokens. There is also an important draft on Enrollment over Secure Transport for provisioning certificates over HTTPS.

Then in the afternoon starting at 13.30 EDT/UTC-4, you’ll need to choose between three working groups. The first TLS session of the week (the meeting continues on Thursday afternoon) has several important items related to the deployment of TLS 1.3 and there’s a proposal to formally deprecate TLS versions 1.0 and 1.1.

There’s two other drafts updating DTLS to version 1.3 (see https://tools.ietf.org/html/draft-ietf-tls-dtls13-28 and https://tools.ietf.org/html/draft-ietf-tls-dtls-connection-id-01), and another describing a TLS extension to allow TLS clients to perform DANE authentication of a TLS server without needing to perform additional DNS record lookups. The remaining couple of drafts on the agenda relate to a mechanism that allows for exportable proof of ownership of a certificate that can be transmitted out of band and verified by another party, and on delegating credentials on TLS to allow server operators to
create their own credential delegations without breaking compatibility with clients that do not support this specification.

Over in SIDROPS, there’s three recommendations up for discussion that network operators avoid using the maxLength attribute when issuing Route Origin Authorizations under RPKI; how to improve Origin Validation within a trusted environment; and definition of a RPKI signed object that can be used by Trust Anchors to allow Relying Parties to migrate to new keys. There’s also a couple of profiles being defined for verifying that a Customer AS holder has authorised a Provider AS to be its upstream provider, and for AS Provider Authorization objects to verify the AS_PATH attribute of routes advertised by BGP. Finally, there will be a discussion on validation deployment planning.

There’s just the two drafts being discussed during the IPWAVE meeting, but important ones. The first is an update of the specification for transmitting IPv6 Packets over IEEE 802.11 Networks in Vehicular communications; the other defines the use cases for IP-based vehicular networks.

For more background, please read the Rough Guide to IETF 102 from Olaf, Dan, Andrei, Steve, Karen and myself.

Relevant Working Groups

Categories
Deploy360 Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) IETF Improving Technical Security Internet of Things (IoT) IPv6 Open Internet Standards Securing Border Gateway Protocol (BGP) Transport Layer Security (TLS)

ISOC’s Hot Topics at IETF 102

The 102nd meeting of the IETF starts tomorrow in Montreal, Canada. This is will be the third time that an IETF has been held in the city, and tenth time in Canada – the first being way back in 1990.

The ISOC Internet Technology Team is as always highlighting the latest IPv6, DNSSEC, Securing BGP, TLS and IoT related developments, and we discuss these in detail in our Rough Guide to IETF 102. But we’ll also be bringing you daily previews of what’s happening each day as the week progresses.

Below are the sessions that we’ll be covering in the coming week. Note this post was written in advance so please check the official IETF 102 agenda for any updates, room changes, or final details.

Monday, 16 July 2018

Tuesday, 17 July 2018

Wednesday, 18 July 2018

Thursday, 19 July 2018

Friday, 20 July 2018

The IETF Hackathon will be held on both Saturday, 15 July 2018 (09.00-22.00 UTC-4) and Sunday, 16 July 2018 (08.30-16.00 UTC-4) in the Centre Ville Room. The Hackathon provides an opportunity for developers and implementers to discuss ideas, solutions and code to develop practical implementations of IETF standards.

The IETF Code Sprint will also be held on Saturday, 15 July 2018 (09.30-16.00 UTC-4) in the Sherbrooke/Mansfield Room. The Code Sprint brings together volunteers from the IETF Community to work on code for the IETF Datatracker, mailing lists, and other tools used by the IETF community.

You can also read the Internet Society’s latest Rough Guide to IETF 102. In particular, see:

If you can’t get to Montreal next week, you can attend remotely!  Just visit the IETF 102 remote participation page or check out http://www.ietf.org/live/ for more options.

Categories
Beyond the Net Building Trust Privacy

How Canadians worked together to shape an action plan for online privacy

Revelations of mass surveillance by government agencies. Invasive new spying legislation. Emaciated and powerless oversight bodies. Canadians have pretty much seen it all when it comes to threats to their online privacy.

In particular, the scale of the privacy intrusions exposed by NSA whistleblower Edward Snowden revealed that the threshold for getting trapped in the government’s surveillance dragnet is problematically low — anyone, at any time, could be a victim and not even know about it.

All this has led to the very real danger that the Internet, the greatest tool for connectivity that humankind has ever invented, will be turned into something it was never intended to be— a tool for governments to spy on the private lives of everybody.

But is that dystopian vision inevitable? Or can citizens, working together, shape a new and positive alternative — a future where we’re every bit as secure in our online homes as we are in our bricks-and-mortar equivalents?

That’s the question my organization, OpenMedia, set out to answer with our Canada’s Privacy Plan project, which was made possible, in part, through a donation from the Internet Society’s Community Grants Programme.

We wanted to see what happens when we gave citizens a real say in terms of how to better protect the online privacy of all of us in an interconnected, digital age. We aimed to better understand Canadians’ priorities and expectations, and use that understanding to work with  experts in creating forward-thinking policy recommendations to address our privacy deficit.

Our project succeeding in involving over 125,000 Canadians in every province and territory, whose input helped shape our final set of key recommendations, that we have since taken forward to key decision-makers in Ottawa.

What worked well?

At OpenMedia, we believe the future of the Internet should be shaped through transparent and participatory processes weighted toward the lived reality of those most affected. As an organization, crowdsourcing is baked into our DNA — we know from experience that the best ideas often come from everyday Internet users, rather than from the Ottawa bubble.

What worked best for us was ensuring that citizens’ input shaped the direction of the project from beginning to end. To achieve that goal, we launched the project with a crowdsourcing tool, to enable participants to rank their privacy priorities in order of preference:

Our accessible and easy-to-use crowdsourcing tool was created to ensure as many perspectives as possible were heard.

This tool asked Canadians what was most important to them in terms of developing effective privacy safeguards. Participants could simply drag-and-drop the priorities in order of preference, and then had the option of either submitting their input, or taking part in a more detailed questionnaire about a range of specific potential proposals to address the privacy deficit. We also gave everyone the opportunity to submit open-ended feedback about what mattered most to them.

The feedback from our tool was invaluable; it was clear from Canadians’ input that 3 issues were of most concern: requiring a warrant to spy on personal info, independent oversight and review of spy agencies, and ending blanket surveillance of law-abiding people. We used this feedback to directly shape the overall direction of the report, and to ensure the key recommendations met the needs of Canadians.

We also successfully engaged Canadians through many other mediums, including a lively Social Media Town Hall, a range of coast-to-coast in-person events in Vancouver, Montreal, and Halifax, ongoing conversations on our website and social media channels, and by working with top experts to create the final recommendations of the report.

Our Facebook Town Hall proved a particularly popular way of engaging Canadians on the issue, and even saw the participation of the official opposition critic on digital rights, the NDP’s Charmaine Borg.

How people responded?

Our small team was really impressed by how many Canadians took the time to participate in our project. Over 125,000 people engaged directly with our privacy work, and over 10,000 of those provided detailed feedback using our crowdsourcing tool.

We were especially pleased by how word of the project spread, as more and more groups and individuals helped share our tool on social media. We even received some help along the way from iconic Canadian author Margaret Atwood, who shared our tool with her over 1 million Twitter followers!

As the person responsible for collating and coordinating our engagement, I think there were some especially inspiring moments along the way:

Firstly, we led two educational events on privacy issues at the B.C. Civil Liberties Association annual event for 16-17 year old high school students. We delivered an interactive presentation outlining the key privacy challenges facing Canadians today. Following Q&As, we followed up with a pen-and-paper exercise that enabled all the participants to take part in our crowdsourcing initiative. Given how deeply embedded the Internet is in the lives of the younger generation, it was truly inspiring to see just how informed and engaged young people are when it comes to their online privacy.

Secondly, simply reading the open-ended feedback provided by Canadians who used our crowdsourcing tool was a remarkable experience. It was humbling to know how many people took the time to craft this often-detailed feedback, while also being hugely valuable in terms of providing an insight into just how personally people view these privacy issues. We received far too many open-ended comments to include all of them in the report, but you can get a flavour by checking out the sampling we included on pages 84-87 of the final PDF. Here are just a few great examples:

  • Maureen told us: “Our electronic mail should have the same safeguards as our physical mail has had for over a century. The government should require a warrant to read any citizen’s communication no matter the form of transmission of that communication.”
  • My name sake David argued: “A judge must be consulted each and every time a government agency wants to invade the privacy of individuals, and the judge must be free from government influence or interference.”
  • Robert emphasized the urgency: “In less than 25 years all privacy rights for Canadians will have vanished. If the people do not speak up now it will be too late.
  • One of our high-school participants Sal summed it all up by arguing that spying “is a threat to autonomy, trespass to the mind. Your most basic human right is your right to be yourself.”

How can other groups replicate this?

We believe the message from our project is clear: rules to better safeguard our online privacy should be created not behind closed doors, but through the participation of all citizens. The Internet can be a powerful tool for more participatory models of decision-making, and we also hope other groups benefit from the detailed methodology section we included in our published plan.

Although this project was both topic- and country-specific (“Privacy in Canada”), we believe our methods could quite straightforwardly be adapted for other topics and settings. While we advise that you check out the full methodology section, some key lessons we learned include:

  • Our low-barrier, interactive crowdsourcing tool was key to maximizing public engagement with the project. We worked to ensure that the questions asked and issues raised were phrased in a way that was accessible to the general (i.e. non-expert) public. We also ensured people could choose to submit their questionnaire at any point, rather than being required to answer every question.
  • From the outset we were clear in our public communications about the crowdsourced nature of the project, the role that participants would play, and the scope of the problem we were seeking a solution to. We explained why it was so important that as many people as possible take part.
  • To shape the questionnaire, we consulted a range of leading privacy experts and organizations, and we are particularly grateful for their assistance when it came to the wording of the more detailed questions about potential privacy reforms.
  • We helped ensure word spread about the tool by including a gamified element, whereby each user received a unique URL they could share, with the people who encouraged the most new participants being recognized on a leaderboard (and even winning privacy prizes such as a year’s free VPN subscription).
  • We worked to ensure the tool would be usable by participants on a range of devices, including tablets and smartphones. A separate version of the drag-and-drop tool was built for mobile device users, with a pull-down menu replicating the drag-and-drop functionality.
  • Publicity was essential: we rolled out a comprehensive communications plan to spread the word about the tool. This included a big push via our website and social media outlets, alongside media publicity and on-the-ground work. We intensified this publicity in the run-up to the deadline with a “last chance to have your say” message.

Our final 96-page report is available here, and readers can also ensure they stay in the loop about our privacy and digital rights work by joining Canada’s Protect our Privacy Coalition, and by following us on our websiteFacebook, and Twitter.

Share this story

If you like this story please share it with your friends. That would tremendously help in spreading the word and raising the visibility of this project. Help more people understand how the Internet can change lives.

Do you have a great idea? We are interested in your project.

We are looking for new ideas from people all over the world on how to make your community better using the Internet.
Internet Society “Beyond the Net Funding Programme” funds projects up to 30 000 USD. 

Find out more

Beyond the Net Funding Programme

Categories
Community Projects Privacy

Crowdsource Privacy Plan

Exciting news! Our organization, OpenMedia, has just launched Canada’s Privacy Plan – a pro-privacy action plan, based on feedback from tens of thousands of everyday Canadians whose ideas shaped it from start to finish.

This ambitious project was made possible, in part, through a donation from the Internet Society’s Community Grants Programme – and our small team here at OpenMedia couldn’t be more grateful. We formally launched the plan at a packed event here in Vancouver – you can check out the photos from our launch party Tumblr here, and read the full version of Canada’s Privacy Plan at PrivacyPlan.ca. We embarked on this project a year ago, with the aim of engaging and informing Canadians  about online privacy issues. Privacy is a matter of growing concern to Canadians who, in recent years, have witnessed a steady stream of revelations about how the government, not least through its Communications Security Establishment (CSE) spy agency, have been spying on Canadians’ private online activities, even going so far as to tap the free wi-fi at a major Canadian airport. We had a number of aims at the outset of this project:

  • We wanted to engage Canadian citizens and experts in creating forward thinking policy recommendations that will address a range of online privacy issues.
  • We wanted to gain a better understanding of Canadians’ priorities and expectations when it comes to privacy.
  • We wanted to learn more about how Canadians want to see their privacy protected in an interconnected, digital age.
  • Finally we wanted to develop a sharable methodology section or toolkit we hope can be used as a model for how the Internet can be used for participatory, policy making.

To engage Canadians, we worked with experts to create an innovative online crowdsourcing tool, to ensure as many perspectives and ideas as possible were heard.

Our tool asked people to tell us what was most important to them when it comes to safeguarding privacy in a digital age. We also asked people for their opinions on a range of proposals aimed at addressing Canada’s growing privacy deficit. We were blown away by the response when we launched this crowdsourcing tool. Thousands of people took part, and our tool was shared far and wide by prominent organizations, with a little help along the way from iconic Canadian author Margaret Atwood. All this invaluable input went directly into shaping our privacy plan. Based on this wealth of grassroots feedback, the report sets out three high-level policy recommendations to roll back our privacy deficit:

  • Get A Warrant:

Require government authorities to obtain a warrant to access Canadians’ sensitive personal information. The report also proposes tougher privacy laws to roll back the information disclosure provisions of Bill C-51 and ensure government agencies use personal information strictly for the purpose it is provided. Despite the Supreme Court’s R. v. Spencer decision last year, much work remains to be done to prevent warrantless access to Canadians’ information.

  • End Mass Surveillance:

Halt all surveillance activities that involve the warrantless collection of Canadians’ personal information, including the bulk collection of deeply revealing metadata. We also propose that surveillance activities require judicial, not political authorization, and that the government cease collecting and analyzing what Canadians say on social media.

  • Embrace Accountability:

Ensure strong, independent oversight and review bodies for the Communications Security Establishment (CSE) and the Canadian Security Intelligence Service (CSIS). Rein in the steep costs of surveillance by requiring the Parliamentary Budget Officer and Auditor General to develop clear cost projections for surveillance activities.

It’s clear that Canadians are absolutely fed up with weak privacy safeguards, spy agency surveillance, and a culture of weak accountability. As Katherine, one of our crowdsourcing participants, said:

“The pendulum has swung WAY too far in the direction of limiting our privacy. Standards need to be adjusted to make privacy the default and transparency must be mandatory.”

Going forward, we’ll be meeting with key decision-makers in Ottawa, to urge them to listen to what Canadians want and adopt the key recommendations of our privacy plan.

Another core goal of our work was to inform other organizations, in Canada and around the world, who may be considering using crowdsourcing methods for their outreach or policy work. Although this project was both topic- and country-specific (“Privacy in Canada”), we believe our methods could quite straightforwardly be adapted for other topics and settings.

The Internet can be a powerful tool for more participatory models of decision-making, and we hope other groups benefit from the detailed methodology section we included in our published plan. You can learn more about how we shaped this project at: https://privacyplan.ca/conclusion/methodology

Finally – and above all else – thank you to the 125,000 everyday Canadians whose input shaped this report from start to finish. It’s just inspiring to know that so many people were willing to give the time to provide their input – and then to help spread the word and encourage others to take part. That’s the power of crowdsourcing – the best ideas come from everyday Canadians far more often than they come from within the Ottawa bubble.

You can learn more about this project by visiting PrivacyPlan.ca.

Categories
Deploy360 Domain Name System Security Extensions (DNSSEC)

CIRA Makes DNSSEC Available For .CA Through Registrars

CIRA logoGreat news today for our friends up north in Canada – they can now sign their .CA domains with DNSSEC! As the Canadian Internet Registration Authority (CIRA) said in a news release yesterday, they are making the Internet safer for all Canadians and noted:

DNSSEC builds a “chain of trust” between users and the websites they wish to visit. It helps counter malicious online activities such as DNS spoofing and man-in-the-middle (MITM) attacks. These fraudulent activities are usually intended to capture personal information, such as bank account logins.

Perhaps even more importantly, DNSSEC will now let people with .CA domains use innovative new protocols like DANE to add a layer of trust to TLS/SSL certificates used for ecommerce and secure access to websites.

CIRA also rolled out an updated FAQ page on DNSSEC (thanks, CIRA, for the link to our work here!) and already has three registrars/DNS hosting providers who will offer DNSSEC-secured .CA domain names.

You may recall that CIRA first made DNSSEC available for .CA domains back in early 2013. However, it was still a manual process to get your signed .CA domain linked in to the global “chain of trust” for DNSSEC.  With this announcement yesterday CIRA has now removed that manual process and made it easy for registrars to upload the necessary DS records. Now they just need more of the .CA registrars to support DNSSEC. (See our page about DNSSEC and registrars for an overview of the process.)

Congrats to the team at CIRA for making this happen!

P.S. If you want to get started with making our domain more secure, visit our “Start Here” pages to learn more about DNSSEC.