Banned on MDN for adding referer warnings, please help.

[Mark Richards]

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...@gmail.com>
Date: Fri, 5 Oct 2018, 13:25
Subject: Re: Edits to <a> and <img> pages on MDN
To: <incl...@mozilla.com>, Chris Mills <cmi...@mozilla.com>
Cc: Geoff White <ge...@gwhite.info>, <case...@ico.org.uk>, Customer
Contact Centre <consumer...@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...@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...@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...@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...@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, <wbam...@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...@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, <wbam...@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
>>>>>>>
>>>>>>>
>>
>

[Bil Corry]

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.


- Bil


On Mon, Oct 8, 2018 at 9:36 AM Mark Richards <mark.alan...@gmail.com>
wrote:

> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security
>

[R0b0t1]

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 Corry]

On Mon, Oct 8, 2018 at 3:23 PM R0b0t1 <r03...@gmail.com> wrote:

> 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.
>

If you read through the thread, it's clear Mozilla asked him multiple times
to stop adding red warning banners to MDN, then revoked his access when he
didn't comply. Do you think there is something different that Mozilla
could have done to handle this situation better?


- Bil