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