/2018
-
Tracy Chou starts off by quoting David Foster Wallace:
The most important education we can receive, Wallace goes on to explain, “isn’t really about the capacity to think, but rather about the choice of what to think about.”
Building on that, the text evolves into a reflection on how little technology education focuses on that latter part – the thinking beyond the technology itself. The text evolves around some anecdotes highlighting the lack of liberal arts and humanities in engineers training:
It worries me that so many of the builders of technology today are people like me; people haven’t spent anywhere near enough time thinking about these larger questions of what it is that we are building, and what the implications are for the world.
And she ends with a wish:
Each of us can choose to learn, to read, to talk to people, to travel, and to engage intellectually and ethically. I hope that we all do so—so that we can come to acknowledge the full complexity and wonder of the world we live in, and be thoughtful in designing the future of it.
Education as the choice of what to think about – this thought really is important. And, one should probably add, this entire phenomenon is maybe even worse in fields like web development where being "self-trained" is a common career entry path?
-
An important report by the Ethics Advisory Group (EAG) of the European Data Protection Supervisor (EDPS):
This report seeks to propose terms and concepts that contribute to a constructive debate about the future of ethics in a full-fledged digital society. It identifies and clarifies some of the ethical questions that emerge in the application of data protection regulations to the new forms of data collection and processing and to the new economy that has rapidly formed around it.
I particularly like the EAG's approach to digital ethics:
The EAG expressly avoids an instrumental approach to ethics of a kind that would result in an ethical checklist or set of measures that, once accomplished, would essentially exhaust ethical reflection and release its practitioners from further discussion. The EAG wishes to discourage approaches to ethics governance that equate data protection with the application of do’s and don’ts.
Ethical conduct in the digital space, they point out, is all about proactive reflection about how technology changes society, where previous policy has fallen short, and what can be done to mitigate the risks emerging as technology develops.
This report proposes concepts and arguments to support and advance data protection as a project of European values. It describes the way traditional concepts of value may be rethought, re-articulated and re-purposed in order to assure the continuity of legitimate practices and anticipate an unseen future.
The report then summarizes their view on that task into five "significant ‘directions’ of thought and innovation":
- The dignity of the person remains inviolable in the digital age
- Personhood and personal data are inseparable from one another
- Digital technologies risk weakening the foundation of democratic governance
- Digitised data processing risks fostering new forms of discrimination
- Data commoditisation risks shifting value from persons to personal data
-
The "Digital Standard", openly maintained under a CC-BY-4.0 license on Github, is an ambitious project to establish shared values in development of software-based products:
Our goals are to enable consumer organizations to test, evaluate, and report on whether new products protect consumer security and privacy, and to empower consumers to make smarter choices about the products they buy.
Covering Security, Privacy, Ownership, and Governance & Compliance, the test categories of the standard can be a handy tool for evaluating these in a product development process.
-
With the byline of "How to become a master manipulator of Visual Communication", Eleana Gkogka provides a neat overview of the Gestalt laws and their importance in UX design:
It’s clear by now, visual design and psychology are linked and can influence one another. Gestalt principles can help us understand and control these links.
This is one of the most comprehensive and well-laid out introductions to Gestalt laws in UX design I have seen – instant add to my usability course's reading list.
-
-
While app developers sometimes acknowledge the fact that a great number of their users do not want to be tracked, and offer them a way to disable targeted advertisements by purchasing paid versions of the same apps, many paid apps still include third-party services such as analytics services that collect unique identifiers, and many developers do not provide any form of control or transparency over how user data is collected, stored and shared with third party services.
This report by the Haystack Project, an academic initiative led by independent academic researchers, draws a chillingly precise picture of the data sharing that takes place in the entirely opaque depths of the mobile app ecosystem. Figure 4 in the report highlights the prevalence of trackers by the organisation behind; e.g.:
Alphabet has penetration in over 73% of all our measured apps with ownership of only 3.6% of all ATS and ATS-C services.
What I find particularly relevant for the discussion of designing for privacy beyond formal compliance with regulations (ref. my recent post on ethical design and human rights), is the "ATS-C" category the authors introduce: while ATS are defined as "Advertising and Tracking Services", ATS-C is a category for "ATS-capable services: third-party services whose primary purpose is not tracking but that may process unique identifiers. Examples stated in the report (figure 3) include:
- fonts.googleapis.com
- googleusercontent.com
- gstatic.com
- fonts.gstatic.com
- googleapis.com
- youtube.com
- googlevideo.com
With the leaking of identifiers to these services commonly covered in "Terms and Conditions" of the app platforms or apps, users are not aware of being tracked this way.
This leads back to general considerations whether any third-party resources can be trusted when designing for privacy - in particular those maintained by the big players in the tracking business like Google, Facebook, etc. (ref. also my earlier post on this topic, building on work by Joel Purra: Tracking is so much more than just cookies).
The bookmarked research paper is not an easy read, but the issues raised deserve a broad public debate ...and it remains interesting to observe how these practices are going to change in the months to come, as many of these are likely to be in massive conflict with GDPR rules.
-
I'd never heard of the Domain of One's Own initiative or similiar before. This is a fantastic, almost revolutionary idea, and actually makes one think whether setting up a personal website with a personal domain shouldn't be part of media education early on, maybe somewhere during secondary education, even?
In particular in times like these, where ad-funded, tightly tracked and algorithmically filtered social networks dominate young people's media habits, learning how to take ownership over opinions, publishing and content.
As this article points out, however, I can see how "forcing" students into using that domain for publishing graded assignments has problematic connotations. If I teach/encourage somebody to "own" their online publishing and identity, I cannot at the same time tell them what is right or wrong to publish there – especially since it is public, and intended to be connected with their identity for good.
(via Chris Aldrich)
-
The wireframes presented in this article should make every UX designer cringe:
Johnny Ryan of PageFair embarks on a step-by-step journey through various GDPR requirements and Article 29 Working Party opinions/guidelines, illustrating how the wide range of purposes adtech companies process personal data for would---when taking the law as literal as possible---require consent dialogues of epic dimensions:
Any individual controllers who intend to process data for their own unique purposes will need further granular opt-ins for these purposes. Since adtech companies tend to deviate from the common purposes outlined above, it is likely that most or all of them would ultimately require granular purpose consent for each controller.
However, even if all controllers pursued an identical set of purposes so that they could all receive consent via a single consent dialogue that contained a series of opt-ins, there would need to be a granular set of consent withdrawal controls that covered every single controller once consent had been given. The GDPR says that “the data subject may exercise his or her rights under this Regulation in respect of and against each of the controllers”.
I'm having a hard time to think of a single user clicking through that (hence the author's verdict that behavioural adtech is doomed). And while it would be easy to put the blame on EU legislation, the real issue is the scale of invasive tracking established on the web today, becoming tangible in this way just as the GDPR intends (what Ryan refers to as "data leakage" is the practice of trackers handing on data to other parties---an uncontrollable mesh for the website publisher who may ultimately be held liable for exposing their site's users to it).
Johnny Ryan has presented a similar exercise before, and I am quite frankly surprised how sparse the conversation is about "consent design" in the UX community. We are 18 weeks away from the GDPR becoming enforceable, and it seems there is only very limited published work on how to obtain consent that would fulfil all the demands of the new EU regulation---in particular when third parties are involved (not just adtech per se, but e.g. integrations of CRM systems, social media platforms etc.). This is the most thorough such exercise I am aware of.
As the laws are what they are, it is "high noon" to alert employers, clients and fellow designers about the fact that the only way to avert the developing UX nightmare that is "compliant consent pop-ups" is to radically rethink how businesses deal with personal data in tracking applications.
Footnotes
- PageFair is selling a product, but the GDPR-based and thoroughly referenced argumentation stands for itself---so no matter the potential "sales" aspect of this text, the design experiments are of great value.↩
-
Pre-GDPR research paper concluding that consent is always needed for behavioural tracking;
This paper argues that in most circumstances the only available legal basis for the processing of personal data for behavioural targeting is the data subject’s unambiguous consent.
According to the author, the analysis would be the same today.
-
A beautifully designed collection of laws that apply in UX (e.g. Fitts' law, and some of the gestalt laws), with introductory texts on their origins and links to related resources. By Jon Yablonski.
Update: In 2020, Jon Yablonski published an extended book version of the "Laws of UX"; for 2022, another release is planned as a card deck
-
Summarizing this classic oversight by a major newsletter service provider, as responsibly disclosed by Terence Eden:
- The referrer (or:
referer, as it is falsely spelled in the HTTP protocol) string of a browser coming from a newsletter contains the ID of the subscriber - Website admin can open the "Manage subscription" page using the ID, but is only presented the obfuscated email address (still able to change the subscription, so this is problematic in itself)
- Clicking on "Unsubscribe" leads to a screen that now contains the unobfuscated email address
Hence, until Mailchimp fixed this vulnerability a good month later, the consequence was:
If you visit a link from a MailChimp newsletter, you risk having your email address and your reading habits broadcast to a site owner.
What can we learn from this?
- Whenever publishing anything on the web, always make a privacy impact assessment of sending any form of referrer URL (and, when in doubt, do not send a
refererheader) - Even if a user ID is known to an outsider, they should not be able to modify a user's data or to determine who is the person behind that pseudonym
These are really two very basic safety steps when designing for privacy. Yet, as the example shows, even big companies whose business is chiefly built upon dealing with personal data sometimes miss these two crucial checks.
- The referrer (or:
-
In this proof-of-concept, Jan Böhmer demonstrates how rather fine-grained tracking can be implemented by CSS-only:
- user clicks
- browser detection
- font detection
- hover duration
- input detection
As the author states, this form of frontend tracking is essentially impossible to block:
The only way that is known to me currently, is to disable CSS for a web page completely […] The problem is that almost every modern web page looks very ugly without CSS and is sometimes even unusable. So, disabling CSS is not a real option […] A better solution would be if browsers didn't load the external content (referenced in CSS) when it´s needed, but when the site is loaded. Then it would be impossible to detect individual actions.
The technique itself is not evil; just as selling kitchen knives does not make the vendor a accomplice in murder, using such technique could also be done for valid reasons. And as long as the data is collected in an ethical and legally compliant manner, that is not a problem (used responsibly, I do not see any difference to pinging a statistics server using JavaScript).
But knowing about a tracking technique that is almost impossible to block – and very hard to detect – leaves a bad feeling knowing how some actors in the data-hungry surveillance industry utilize any loophole they can. This attack vector is particularly important to consider when embedding third-party code – this would open an avenue for the remote party to track users without their control.
-
The Belgian DPAs information website on privacy for young people (in French/Dutch) provides information material for young people and parents on how to protect their privacy. A nice example of educational material in the field of online privacy.
Also has a very stylish "cookie banner" solution!
-
Third-party scripts are probably the #1 cause of poor performance and bad UX on the web.
Chris Coyer collects a range of sources that explain why third-party scripts on websites – and handing control over them to the marketing department – is bad for performance, security and privacy.
-
Amen!
-
Free/libre Google Analytics -alternative Piwik is now "Matomo": no matter the name, the tool remains #1 choice for independent web analytics. #GDPR
-
Marcus Povey describes why a website should not show webmentions with embedded images from the source site (as it could allow the publisher of the source site to track the audience of the cited site).
This is not Webmention or Indieweb specific, but a general privacy risk: whenever loading resources from a third party, that might enable them to track a user.
(Not mentioned in the post, but the suggested solution of caching the images of course opens yet another can of worms: strictly speaking that might be a copyright infringement, unless the owner of the profile image has consented to it being copied.)
-
We have built the digital world too rapidly. It was constructed layer upon layer, and many of the early layers were never meant to guard so many valuable things: our personal correspondence, our finances, the very infrastructure of our lives.
Zeynep Tufekci pinpoints the vulnerabilities of computers due to the technological debt they carry along; why aren't computer bugs scrutinized with the same rigor as for example plane crashes?
-
The internet is a great thing. It is also the biggest machine on earth, and it runs mostly on coal, which is bad news for our climate.
The Planet Friendly Web Guide is an ongoing work-in-progress, written in the open (which in itself makes this an interesting project), that aims to be an educational resource based on a clear mental model:
The planet friendly web guide is an open source, freely available guide, combining an easy-to-understand mental model to help you think through what you can do and why, with focussed guides showing how you can make these changes, drawing on techniques from fields ranging from service design, user experience, web performance optimisation, and technical architecture.
-
A fictional story showcasing a smart (social engineering) exploit to use npm packages as a backdoor vector for malicious code.
On any page that collects any data that you don’t want me (or my fellow attackers) to have, don’t use npm modules. Or Google Tag Manager, or ad networks, or analytics, or any code that isn’t yours.
The author even illustrates how a CSP header will not fully prevent this kind of attack. In the end, it boils down to the summary of the article:
My goal (as it turns out) is simply to point out that any site that includes third party code is alarmingly vulnerable, in a completely undetectable way.
The recommendation would be to use sandboxed iframes with hand-crafted JS for any sensitive input pages.