On Mon, Oct 8, 2018 at 2:48 PM Bil Corry <b...@corry.biz> wrote:
>
> Hi Mark,
>
> Wow, there's a lot to unpack in this email thread.
>
> I'm not clear what you're asking for, I think you want community support to
> add back in your warning banners regarding referrer privacy issues. If so,
> please send a new email to the community asking for opinions about adding a
> warning banner and mention that Mozilla is against adding the banners, but
> please do not quote this entire thread. I have some thoughts about your
> ask, but this thread is now unfortunately about the nature of your
> disagreement with Mozilla instead of the substance. A new thread will
> allow you to seek community feedback about your specific ask.
>
> Regarding Mozilla's behavior and your own; my interpretation reading
> through the thread is that Mozilla heard your feedback, incorporated it
> into MDN according to how they manage their content, and asked you not to
> add the warning label. It escalated and they revoked your access to modify
> content.
>
If they did ban him with no warning for proposing a feature(?) then I
think it is worth mentioning. There have been other very strange
executive decisions that I think need discussed as well, mostly
related to how ads are served in Firefox, but I don't want to bring
them up right now.
Cheers,
R0b0t1
>
> - Bil
>
>
> On Mon, Oct 8, 2018 at 9:36 AM Mark Richards <mark.alan.richa...@gmail.com>
> wrote:
>
> > Hey
> >
> > I've had my MDN account banned for trying to add referer warnings onto <a>
> > and <img> elements or worse banned for involving authorities who are
> > investigating the mess of microtargeting. It appears MDN are refusing a
> > warning on the grounds it isn't a nice presentation, regardless of how
> > irresponsible it is to not include it.
> >
> > I need help and as the security devs I hope given the extent to which
> > Firefox has added config features and policies to try to reduce the referer
> > mess there are community members who understand how significant this is.
> > Whatever Firefox tries, other browsers have a bigger market share.
> > Documenting the referer risks in MDN does stand a chance of better
> > educating developers so they start paying attention to their third parties
> > and for many it is imperative to do so given GDPR changes.
> >
> > A developer I know who recently finished a three month intensive course on
> > the web advised there was no coverage of referer, which matches my CS
> > degree experience over a decade ago. This isn't a one-off to me, I have met
> > many developers who don't understand the risk or even have misconceptions
> > about how it works (like thinking it's not sent on https sites). However
> > this developer did say the course used MDN to teach about the web features
> > and this matches my development experience, MDN is very much respected by
> > the Dev community. It may well be the case MDN has a greater market share
> > in the Dev community as an educational resource, than Firefox does with
> > consumers as a browser.
> >
> > The Mozilla security blog has been multiple references to referers over the
> > years, but most people are still having their browser history distributed
> > piecemeal by it. Browsers still don't protect referers by default and even
> > if that changed tomorrow it might be 5-10 years before everyone upgrades
> > their various devices.
> >
> > https://blog.mozilla.org/security/2015/01/21/meta-referrer/
> >
> > https://blog.mozilla.org/security/2018/10/02/supporting-referrer-policy-for-css-in-firefox-64/
> >
> > https://blog.mozilla.org/security/2018/01/31/preventing-data-leaks-by-stripping-path-information-in-http-referrers/
> >
> > With GDPR, the rules changed and are being copied in other jurisdictions.
> > Businesses must have accountability and privacy by default, so referer is
> > in conflict with local legislation not just because privacy or security
> > breaches may have happened, but primarily because a business has to assess,
> > document and decide on the risks of which systems get data about a user of
> > their sites. Profiling of users, made possible by referers by default, was
> > one of the motives for GDPR so is rightly part of regulators investigations
> > now, but I'm not sure the regulators realised that the technical feature at
> > the centre of it is the referer and how broken the web is for privacy.
> > Tracking pixels are an image, a cookie and referers... The cookies have
> > long been part of data protection discussions and laws, yet you can profile
> > someone without a cookie (IP address) you can't do it without the referer
> > (unless explicitly add the same functionality by code to the url, at which
> > point it is an explicit act and can be justified by the author). Many
> > places shouldn't get a referer, like CDNs. Most CDNs need to know who to
> > charge (API key?) not a full referer.
> >
> > China is very interesting, the headlines aren't necessarily fines for data
> > protection violations but over 11000 arrests. How many of those are web
> > developers or directors of companies because of their website? How many
> > will it be in the future as regulators realise it's not the ad companies
> > that steal this data, but it's given away by websites protecting users
> > referers?
> >
> > https://asia.nikkei.com/Business/Business-Trends/China-s-strict-new-cybersecurity-law-ensnares-Japanese-companies
> > .
> >
> > UK has criminal prosecution options in its data protection laws and I hope
> > that those in the UK responsible for keeping tracking on the NHS website
> > face criminal prosecution (they had ample warning given it hit the news in
> > 2010), but what is often amazing in raising complaints (which I've been
> > doing for years now relating to referer leaks) is how often I'm advised by
> > companies they don't send personal data, even when they load tracking on
> > membership pages or similar that give away data that might put lives at
> > risk in the wrong hands (various UK political parties have a history of
> > being targeted by terrorism and they sent their membership lists to ad
> > companies by loading tracking on members only areas, I've been advised by a
> > major UK political party that they're under investigation for tracking).
> >
> > For anyone hands on with privacy impact assessments, you'll know you have
> > to document which systems and third parties get personal data and a user's
> > browsing habits linked to just an IP address, nevermind cookies, is
> > personal data (most of us having relatively long lived IP addresses, even
> > when not static, like those unique to our mobile device or family
> > internet). If developers aren't thinking about referers, they're not
> > completing their privacy impact assessments properly or advising their data
> > protection officer/management properly about third parties that may be
> > added outside of Dev workflows. By not doing this work they're unlikely to
> > being private by default/design...they're likely breaching GDPR and
> > similar.
> >
> > I'm really appalled at Chris for tearing down this warning, but less so of
> > Mozilla if it's just a couple of guys who think presentation is more
> > important than privacy and security. Which is it? Can you help fix this
> > mess. Whatever web browsers do about referers, at least make it a priority
> > to tell web developers so they can protect users instead.
> >
> > Regarding the security aspect, please look at how many websites you use in
> > your password manager and start resetting your passwords. You might be
> > amazed at how many ad companies get tokens to take over user accounts, how
> > long lived they are and how many are re-usabale for days.. One finance
> > company advised me 5% of their reset password requests involved multiple
> > IPs as users didn't complete the first attempt and hopefully just changed
> > device or network. Meanwhile URLs are often a place of security failings
> > like jsessionid in the URL or even usernames and passwords for startups who
> > accidentally use GET instead of POST for a form or just users who type a
> > password and press enter. The sharing link problem hit Dropbox previously
> > where if you opened content in Dropbox that included a link to a third
> > party, that third party was sent the referer (the share link)
> > https://www.grahamcluley.com/dropbox-vulnerability-privacy/
> > Dropbox have hopefully fixed this, but what will the next popular user
> > content site do? We keep repeating the same mistakes when it comes to
> > referer and a very obvious reason for repeating a mistake in a community is
> > a lack of education about how easy it is to make that mistake.
> >
> > Regards
> > Mark
> >
> >
> >
> >
> > ---------- Forwarded message ---------
> > From: Mark Richards <mark.alan.richa...@gmail.com>
> > Date: Fri, 5 Oct 2018, 13:25
> > Subject: Re: Edits to <a> and <img> pages on MDN
> > To: <inclus...@mozilla.com>, Chris Mills <cmi...@mozilla.com>
> > Cc: Geoff White <ge...@gwhite.info>, <casew...@ico.org.uk>, Customer
> > Contact Centre <consumer.quer...@fca.org.uk>
> >
> >
> > Chris,
> >
> > What is wrong with the action of trying to protect users?
> > Why do you perceive that action as wrong?
> >
> > I've explained my attitude and the content, has always been to protect
> > people. The content has kept to that narrative and I don't need to write an
> > essay to justify anything more than is obvious from what I've written. Your
> > questions are not a requirement for other contributors and I'm not sure
> > what you are trying to moderate by me answering them? Do you want to
> > moderate what kinds of people can contribute or just whether their
> > contributions are appropriate?
> >
> > If Mozilla's position is that anyone who turns to regulators and
> > journalists to raise awareness of an issue should be banned from
> > volunteering their time, then I think the regulators should investigate
> > whether this breaches laws for protecting disclosure in the public
> > interest. Organisations are not supposed to punish individuals for the act
> > of involving regulators and your justification for banning me appears to be
> > based in part on the claim I've "threatened" by involving them. Sorry, but
> > whatever threat you perceive, it's justified. Like when someone calls the
> > police, if they spot something wrong and they don't have control over it...
> > They involve authorities that can protect others or react. You don't appear
> > to recognise the difference between being challenged and being
> > threatened... It's not nice to be on the receiving end, but that doesn't
> > justify penalising the person who challenged you.
> >
> > Regarding your moderating..
> > Multiple people have tried to put the warning on the web docs and you've
> > torn it down. Mozilla is supposed to be a community driven project, yet
> > you've shunned the community. Do think I misled those users or do you think
> > I explained the situation honestly and they were appalled too?
> >
> > Let's be clear...
> >
> > If a teacher shows kids how to use scissors and doesn't tell them the
> > dangers of sharp objects, not to run with them, how to hold them safely,
> > etc until an optional further lesson, I'd hope they could be jailed if made
> > aware of the error of their ways and told of numerous incidents already,
> > they continue regardless.
> >
> > You to me are like that teacher... You are teaching web developers how to
> > create websites, without explaining that by default they will break the law
> > in many countries and more importantly, they'll be breaching user privacy
> > which is a human right beyond whether local laws have caught up.
> >
> > Your actions and attitude suggest you cannot be reasoned with. You refuse
> > to acknowledge the conflict with social norms and that no reasonable person
> > can accept your deletion of the warning. Nobody in their right mind takes
> > down a warning sign when there is significant evidence that people need it
> > and are suffering.
> >
> > Billions of people are being surveilled by the ad industry, there is an
> > incredible invasion of privacy at the centre of the Referer leaking users
> > web history. Whatever people campaign about changing the web, Mozilla as an
> > organisation that makes a web browser and offers documentation for web
> > developers, should not be deleting warnings of this and it puts into
> > question Mozilla's purpose, as it's a not for profit, obliged to act for
> > the public benefit, this appears to be an intent to put people in harms
> > way.
> >
> > Again, please take a step back and consider this from the position of
> > someone who has realised how significant the harm of the referer is, took
> > the time to add a warning to protect others and had it taken down.
> >
> > Regards
> > Mark
> >
> >
> >
> >
> > On Thu, 27 Sep 2018 at 12:13, Chris Mills <cmi...@mozilla.com> wrote:
> >
> > > Hi Mark,
> > >
> > > I get your first point here. The trouble however with such situations is
> > > that the intent doesn’t really matter if how others perceive your actions
> > > comes out wrongly/badly.
> > >
> > > Yes, we are a community site, and we spend a lot of time mentoring
> > > community members, helping them get content up online, settling disputes,
> > > etc. But one key feature of a community is that there are moderators, and
> > > if a moderator asks you to stop doing something, they probably have a
> > good
> > > reason for doing so. From the moderator’s point of view, it is a real red
> > > flag if a new community member is asked to stop doing something, and they
> > > respond by ignoring you and sending you long, aggressive mails that are
> > > perceived as shouty and threatening. I banned you because I honestly
> > didn’t
> > > feel there was any other way forward. I didn’t believe that reasoning
> > with
> > > you would work because you seemed unreasonable, in the literal sense of
> > the
> > > word.
> > >
> > > I also acknowledge that you didn’t directly threaten anyone, but several
> > > times you used prose along time lines of “all of these bad things will
> > > befall people who read your pages if I don’t get my way”, which does come
> > > across as threatening, albeit indirectly. And cc’ing regulatory bodies
> > and
> > > journalists on the mail serves to make us feel bullied, like a witch
> > hunt.
> > > Again, this isn’t going to make us more likely to listen to your point of
> > > view.
> > >
> > > Anyway, we could argue about the minutiae of our interactions all day
> > > long, but it would probably be more productive to draw a line in the sand
> > > and do better going forward.
> > >
> > > ------
> > >
> > > I now believe we can make some progress — in this last mail you have
> > shown
> > > some empathy towards our situation. I’d like to afford you the same good
> > > treatment, and say sorry if our actions came across as aggressive. I also
> > > believe that you have good intentions — you want to contribute to a more
> > > secure, privacy-aware web, and I think you should be applauded for that.
> > I
> > > agree with many of your points; I’ve been a web developer and tech writer
> > > for 20 years, and understand many of the issues you highlight here. I
> > think
> > > we both want a lot of the same things, and can help each other, provided
> > we
> > > can compromise to find a middle ground that makes you happy but also
> > works
> > > with our content strategy.
> > >
> > > I‘m happy to unban you if I can get your agreement that you’ll listen to
> > > our moderators and respect our wishes, and engage in constructive
> > > discussion about prospective content.
> > >
> > > I’d also like you to answer a question for me — what would you like to
> > see
> > > in terms of MDN content going forward? Give me a high level description,
> > > not too much detail at this stage.
> > >
> > > Things we can do:
> > >
> > > * Add more content about security/privacy best practices related to front
> > > end web dev. We are a web development tutorial site, and this is
> > definitely
> > > in our remit.
> > > * Add warnings in a tasteful way that works for our content strategy. We
> > > have a plan for the near future to add a dynamically-constructed banner
> > at
> > > the top of reference pages that highlights concerns with that web
> > feature,
> > > e.g. privacy, security, accessibility, performance…
> > > * Add additional Security and privacy concerns sections to other pages
> > > that need it. I am very interested in providing such information.
> > >
> > > Things we can’t do:
> > >
> > > * Provide extensive regulatory/policy/legal advice. This is a minefield
> > > that we do not have the time or knowledge to walk through.
> > > * Change the web platform. I am not going to, for example, help with a
> > > campaign inside Mozilla to get rid of the Referrer header, or make it
> > leak
> > > no data by default. If Mozilla did that, lots of huge sites that rely on
> > > tracking, etc. for their business model would block Firefox, then we’d
> > lose
> > > our market share and there’d be no Firefox at all. Such discussions would
> > > have to start on a W3C level. It’s the ugly truth. I hate it as much as
> > you
> > > do, believe me.
> > > * Add lots of random red banners everywhere. If we did this for every
> > > different person who came along and wanted red banners to support their
> > > chosen cause, MDN would be a complete mess, and no-one would take it
> > > seriously. We have lots of evidence to support the notion that scary
> > > banners don’t really make much different at all — established web devs
> > tend
> > > to jump around and use specific items in reference pages, such as the
> > code
> > > example, or the compat data. They tend to ignore such banners. Beginners
> > on
> > > the other hand are more likely to read the Whole page but probably won’t
> > > really get it or why it’s important, and be put off by it. They need to
> > > know what an <a> element is first, before being bombarded with scary
> > > warnings. We need a different approach.
> > >
> > > Best regards,
> > >
> > > ---
> > >
> > > Chris Mills
> > > MDN content lead & writers' team manager
> > > MDN Web Docs
> > > Mozilla
> > > @chrisdavidmills
> > >
> > > On Sep 26, 2018, at 9:35 PM, Mark Richards <mark.alan.richa...@gmail.com
> > >
> > > wrote:
> > >
> > > Chris,
> > >
> > > You're mixing up protest with inappropriate aggressive behaviour.
> > >
> > > The two are different and whilst protest is aggressive, it is a warranted
> > > form of expression, typically protected by law. I have not expressed any
> > > aggression that would seek to harm you. Protest is not an enjoyable
> > > experience to be on the receiving side of, sorry to you and Will for
> > this.
> > > It is not enjoyable for me to feel this is a necessary act and you
> > engaged
> > > in starting a protest against my addition of the warning, so I'm guessing
> > > we probably share some similar feelings about this situation and given a
> > > position reversal maybe I would have blocked you.
> > >
> > > I've been active on the problem of Referers on and off for three years,
> > > I'm not stopping today. I've seen enough data lost to third parties and
> > not
> > > just reset password links, but session login tokens that expired after a
> > > year and usernames and passwords used in form GET requests (default
> > > behaviour of a form is a GET and nobody should use this, another problem
> > > with browsers from retaining 1990s design, but if a site uses JavaScript
> > to
> > > process the form the Dev can swap to an Ajax post, but if the developer
> > > isn't defensive in setting the method anyway to post or put, then when
> > the
> > > script fails to load in time or because of a network failure (which isn't
> > > unlikely on mobiles) then the browser will by default perform a GET and
> > > leak the username and password to third parties tracking the same page...
> > > Had the script loaded it would have overwritten the behaviour.. this is
> > > more common that you might have thought. It's not just scripts not
> > loading
> > > either, if the script hits an exception before changing the default
> > > behaviour of the form, the form will remain in the GET default, so if the
> > > form validation logic hits something unexpected, it might not get around
> > to
> > > changing the submission behaviour).
> > >
> > > Please don't fight to hide this warning as a footnote developers might
> > > find. I'm not the only one who cares about this and I hope others protest
> > > too about Mozilla removing this warning. I am likely one of the minority
> > of
> > > developers who goes out of their way to research this topic and I would
> > > encourage you to try some research.
> > >
> > > Mayhe use the web and check what referers you can find leaked and to
> > whom.
> > > You can probably turn on har data logging in Firefox, chuck it into a
> > JSON
> > > file over a few months and then parse that into a database, maybe Elastic
> > > Search and search for who got your email, who knows which websites you
> > > visited, did anyone get a password, etc. You'll need to do this without
> > any
> > > privacy plugins enabled that might stop third parties loading or changing
> > > referers. Sadly the best research can often put the researcher at some
> > > risks, so only do this if you are comfortable doing it.
> > >
> > > Meanwhile, please take a step back and look at this again.
> > >
> > > Note: I did also sympathise with your position about a bold red warning
> > > and when the block of text I wrote moved down the page, I only put a
> > small
> > > 1-2 line warning... I was trying to be respectful of your or Will's
> > > position at the time and since asked repeatedly if you had any ideas to
> > > keep something at the top of the page that achieves the same goal. To
> > which
> > > you both just kept deleting it and led us to this state.
> > >
> > > Best
> > > Mark Richards
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Wed, 26 Sep 2018, 17:45 Chris Mills, <cmi...@mozilla.com> wrote:
> > >
> > >> (removing all the other e-mail addresses you've attached to the mail, as
> > >> I don't know these people or their involvement in this. Also removing
> > Will.)
> > >>
> > >> Hi Mark,
> > >>
> > >> I'm Chris, Will's manager.
> > >>
> > >> I see that you've again ignored our multiple requests to stop reverting
> > >> our changes. You've also sent us multiple emails that have come across
> > as
> > >> aggressive and somewhat threatening. And all of this after we have taken
> > >> multiple steps to meet your content demands, but in a way that works for
> > >> our content strategy. I therefore have no choice but to ban your
> > account.
> > >>
> > >> This is a shame, and not something I enjoy doing or take lightly. We
> > >> agree with many of your points of view, however we also have our own
> > >> reasons for wording and presenting documentation like we do, and we have
> > >> the ultimate say on MDN content disputes. This must be respected before
> > we
> > >> can engage with contributors in a meaningful way.
> > >>
> > >> Best regards,
> > >>
> > >> ---
> > >>
> > >> Chris Mills
> > >> MDN content lead & writers' team manager
> > >> MDN Web Docs
> > >> Mozilla
> > >> @chrisdavidmills
> > >>
> > >> On Sep 25, 2018, at 2:45 AM, Mark Richards <
> > mark.alan.richa...@gmail.com>
> > >> wrote:
> > >>
> > >> Chris and William,
> > >>
> > >> This page will mislead web developers.
> > >>
> > >>
> > https://developer.mozilla.org/en-US/docs/Web/Security/Referer_header:_privacy_and_security_concerns
> > >>
> > >> I don't want to improve it, because this nature of document should be
> > >> centre stage of the Referer page
> > >> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer
> > >>
> > >> The referer unexpectedly (most users don't know this happens, even a
> > >> surprising number in the tech community don't) sends the page you are
> > >> currently on to the target when their content is loaded on a page (like
> > an
> > >> image) or when you follow a link to their page.
> > >>
> > >> By design this is a breach of privacy, if the target is a third party.
> > >> They are being told you are a used of the origin website and that's
> > >> personal data about someone's activities, often mapped to an approximate
> > >> identity (psuedonym, IP address, etc) or real identity ( a user account
> > on
> > >> the target) and allows for things like discrimination.. coming from a
> > >> religious site to a shopping site and will their stock still be
> > available?
> > >> There are innocent use cases, but you're misrepresenting them.
> > >>
> > >> Obviously, the internet is full of ad tracking and this is the glaringly
> > >> obvious problem hitting headlines about legal cases and regulatory
> > action
> > >> in various countries, but what you've described as "innocent" largely
> > isnt
> > >> to be ignored and it is the reason why I titled the section originally
> > as
> > >> not just about privacy and security, but regulatory concerns. If the
> > >> targeting disappeared tomorrow, this would still need to be a feature
> > all
> > >> web developers need to understand.
> > >>
> > >> If a website uses logging, analytics or cache optimization, from a third
> > >> party, which is often the case these days, if the web developer does not
> > >> understand what data the third parties get, then they may have just put
> > >> their business at risk of breaching regulations, like the data
> > protection
> > >> laws, which require appropriate consideration for consents,
> > accountability
> > >> and inclusion in documentation to users as privacy policies.
> > >>
> > >> So regardless of how innocent any of these services are, deelopers will
> > >> have let down themselves, their business and their users, to an extent
> > that
> > >> could result in fines, legal action and distress, if they fail to
> > realise
> > >> the exact page users are visiting is shared with the target and taken
> > >> appropriate steps to let the business update consent flows, update GDPR
> > >> impact assessments, policies, risk registers and anything else that
> > might
> > >> be a further requirement of any industry specific regulation for where
> > they
> > >> may operate (health, finance, government, military clinical trials, etc
> > may
> > >> well require additional processes and outputs beyond GDPR).
> > >>
> > >> So unless you want a lot of data protection officers facing
> > >> investigations, businesses facing fines and web users distressed, even
> > >> considering legal actions against websites, please don't play down the
> > >> significance of managing referer headers properly. Every single web
> > >> developer needs to know and it might be about nasty ad tracking, but
> > >> there's a much bigger reason why every developer needs to know and it
> > may
> > >> get them fired.. as for the whole of the EU, there has to be an
> > >> understanding as part of meeting GDPR and EU privacy directive and
> > similar
> > >> regulations are being drafted or already exist in various countries
> > around
> > >> much of the world.
> > >>
> > >> If you don't understand my motives for the changes I've made or don't
> > >> understand the breadth of why it is so important that Mozilla ensure
> > there
> > >> is appropriate guidance for web developers, then actually talk about it
> > >> instead of just deleting someone's work or amending it to lessen the
> > >> significance...ask me questions as to why I've worded something this
> > way,
> > >> it is not with malice, it is to help protect web users, developers and
> > >> businesses.
> > >>
> > >> I'm really frustrated that Mozilla has failed on privacy so
> > significantly
> > >> for so long, but I'm trying to play a positive role in helping to
> > improve
> > >> that by updating docs to help developers avoid the privacy, security and
> > >> regulatory compliance holes it's so easy to fall into when making
> > websites.
> > >> If browsers could remove those holes, great but until then we need these
> > >> docs.
> > >>
> > >> You're supposed to care about privacy too, so please research and
> > >> understand the problem fully. Read the ICO guidance on impact
> > assessments,
> > >> privacy policies, microtargeting, consent, accountability, privacy by
> > >> design and default... Please understand what you are risking by removing
> > >> this and why what may appear as an innovative use case, is actually a
> > >> trigger for a chain of business processes to ensure that it is innocent
> > and
> > >> the business can account for that to its users and regulators.
> > >>
> > >> I am grateful you've made an effort to keep some of the intent of my
> > >> work, but I'm not at all happy about the attitude shown here and it does
> > >> not help that you don't appear to understand. I asked in a previous
> > email
> > >> to get your legal team involved and corporate social responsibility
> > team:
> > >> not because I plan to take legal action or ask for donations... But
> > because
> > >> they hopefully have the expertise to read into the regulatory concerns
> > and
> > >> the privacy issues raised and play a part in identifying the need for
> > this
> > >> documentation instead of throwing businesses into the line of fire of
> > data
> > >> protection mishaps.
> > >>
> > >> Best
> > >> Mark Richards
> > >>
> > >>
> > >> On Mon, 24 Sep 2018, 21:20 Mark Richards, <mark.alan.richa...@gmail.com
> > >
> > >> wrote:
> > >>
> > >>> Chris,
> > >>>
> > >>> Is it really necessary to continue to remove the warning?
> > >>>
> > >>> If you walk into a building and the tiled floor is wet, people might
> > get
> > >>> hurt, so you put a sign up and you warn them. You don't state, "but the
> > >>> bright yellow sign doesn't fit with the design of the elegant hallway"
> > ...
> > >>> sorry, but sometimes there are more important matters than design and
> > you
> > >>> have to live with inconvenience because it's the right thing to do.
> > >>>
> > >>> If a browser feature by default, by design, functions in a manner that
> > >>> leaks private data (something that likely was not as obvious a concern
> > in
> > >>> what 1996(?) when referer was included in the HTTP RFC) then shouldn't
> > you
> > >>> put a warning up first, before more developers cause more harm to the
> > >>> public?
> > >>>
> > >>> It is wrong to take the sign down and leave a note up towards the end
> > of
> > >>> the tiled floor, long after many will have already fallen over stating
> > be
> > >>> careful, details in another room. So why are you doing this?
> > >>>
> > >>> I'm sorry it's not pretty, warning signs aren't and I'm sure many
> > >>> products wished they didn't need to include smoking kills, flammable,
> > not
> > >>> suitable for children, heavy load, ... warnings. Why is it okay for
> > the web
> > >>> to not warn people first, when everyone else has to?
> > >>>
> > >>> Best
> > >>> Mark Richards
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On Sat, 22 Sep 2018, 15:45 Mark Richards, <
> > mark.alan.richa...@gmail.com>
> > >>> wrote:
> > >>>
> > >>>> William please can you involve your corporate social responsibility or
> > >>>> similar department and legal team.
> > >>>>
> > >>>> I'm sorry, but again this is not appropriate.
> > >>>>
> > >>>> If you now go to
> > >>>> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a
> > >>>>
> > >>>> You are first taught how to abuse someone's privacy by writing
> > insecure
> > >>>> code that leaks referers identifying users online habits.
> > >>>>
> > >>>> Of many complaints to data protection officers this year, sitting in
> > >>>> the centre of my complaint is that the website is sharing the pages
> > people
> > >>>> visit, so healthcare organizations identifying people who are
> > interested in
> > >>>> HIV to ad companies, political parties revealing their membership to
> > ad and
> > >>>> analytics companies, even a religious site identifying who intends to
> > >>>> pray... These are all sensitive data. The reset password concerns
> > including
> > >>>> public health sites and a credit report company.
> > >>>>
> > >>>> Only if your habit is to read the whole document, beyond what you
> > need
> > >>>> to get something working, would you then later discover that the
> > default
> > >>>> implementation of web links is to breach privacy and in too many cases
> > >>>> security.
> > >>>>
> > >>>> So, you've repeated exactly what I asked you not to do and continue to
> > >>>> teach web developers how to abuse people's privacy and security and
> > leave
> > >>>> them to maybe later find out what they got wrong.
> > >>>>
> > >>>> For a company that claims to care about privacy, you seem determined
> > to
> > >>>> put people in harms way.
> > >>>>
> > >>>> So please try again and stop hiding the design failures in your
> > product
> > >>>> to pages people might chance on, not need to see.
> > >>>>
> > >>>> Regards
> > >>>>
> > >>>> Mark Richards
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> On Sat, 22 Sep 2018, 15:22 William Bamberg, <wbamb...@mozilla.com>
> > >>>> wrote:
> > >>>>
> > >>>>> Hi Mark
> > >>>>>
> > >>>>> We've discussed this internally, and this is what we're going to do:
> > >>>>>
> > >>>>> * write a separate page outlining security and privacy concerns
> > around
> > >>>>> the referer header, and mitigations. We've drafted some content at
> > >>>>>
> > https://developer.mozilla.org/en-US/docs/Web/Security/Referer_header:_privacy_and_security_concerns
> > .
> > >>>>> We think this should concentrate on tools and designs available to
> > combat
> > >>>>> these problems (such as the Referrer-Policy header, and making
> > password
> > >>>>> reset URLs single-use) rather than on auditing every target.
> > >>>>>
> > >>>>> * link to this page from relevant pages, such as the page for the <a>
> > >>>>> and <img> elements.
> > >>>>>
> > >>>>> We don't think it's appropriate to have a red warning banner at the
> > >>>>> tops of the pages. That kind of design element is one we try to
> > avoid on
> > >>>>> MDN unless it's highlighting the very first thing you need to know
> > about
> > >>>>> the item, which we don't think it is in this case, although we do
> > >>>>> appreciate that it is important.
> > >>>>>
> > >>>>> Thanks for bringing this up.
> > >>>>>
> > >>>>> Will
> > >>>>>
> > >>>>>
> > >>>>> On Sat, Sep 15, 2018 at 7:50 PM Mark Richards <
> > >>>>> mark.alan.richa...@gmail.com> wrote:
> > >>>>>
> > >>>>>> When a feature's default implementation puts people in harms way,
> > >>>>>> then users need a warning to protect themselves and others.
> > >>>>>>
> > >>>>>> Is it Mozilla's position to teach software developers how to use
> > >>>>>> features in a manner that leaks data, leaving details of how to
> > avoid it,
> > >>>>>> towards the end of documentation, rarely to be found?
> > >>>>>>
> > >>>>>> I'm have been and currently am involved in various complaints to
> > >>>>>> regulators regarding companies in finance, health, politics and
> > religion
> > >>>>>> all disclosing data because of these privacy and security failings.
> > >>>>>>
> > >>>>>> In some cases putting account security at risk allowing for access
> > to
> > >>>>>> Investments or to take out loans in someone's name or data that
> > could
> > >>>>>> easily put some people easily in harms way in the wrong hands.
> > >>>>>>
> > >>>>>> I do not mind if you have an innovative suggestion that educates
> > >>>>>> developers about how to protect privacy when using these features,
> > but
> > >>>>>> until then it seems appropriate to consider lengths as far as the
> > "smoking
> > >>>>>> kills" style warnings on cigarette packaging, to the documentation
> > for the
> > >>>>>> website... I've not gone that far.
> > >>>>>>
> > >>>>>> So do you care about privacy or do you want to teach the next
> > >>>>>> generation of web developers how to create websites that put people
> > at risk?
> > >>>>>>
> > >>>>>> If you have a better solution than the warning message please
> > propose
> > >>>>>> it instead, but don't delete warnings there to protect people from
> > the
> > >>>>>> privacy failings endemic the design of the web specs.
> > >>>>>>
> > >>>>>> Best
> > >>>>>> Mark
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> On Sat, 15 Sep 2018, 19:29 William Bamberg, <wbamb...@mozilla.com>
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>>> Hi
> > >>>>>>>
> > >>>>>>> Thanks for the contributions you've made to MDN. I do appreciate
> > you
> > >>>>>>> drawing attention to the privacy issues around certain HTML
> > elements such
> > >>>>>>> as <a> and <img>.
> > >>>>>>>
> > >>>>>>> However I'd like to request that you stop reinstating the "warning"
> > >>>>>>> banner at the tops of the pages. There are very few situations in
> > which
> > >>>>>>> it's appropriate to use this banner at the top of the page, and I
> > don't
> > >>>>>>> think it's appropriate in this situation.
> > >>>>>>>
> > >>>>>>> Thanks
> > >>>>>>>
> > >>>>>>> Will
> > >>>>>>>
> > >>>>>>>
> > >>
> > >
> > _______________________________________________
> > dev-security mailing list
> > dev-security@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security
> >
> _______________________________________________
> dev-security mailing list
> dev-security@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
