Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

[Josh Smeaton]

I agree that "dangerously" doesn't and shouldn't be in the name - it's 
unnecessarily verbose.

I think a name like "no_escape" ,or similar, conveys the meaning properly 
and is no more verbose than mark_safe.


On Thursday, 20 February 2020 10:16:12 UTC+11, Kye Russell wrote:
>
> Personally I think that the current name does a fairly good job of 
> conveying the effect, and this is coming from someone who doesn’t 
> explicitly understand the internal process and is merely inferring it. 
>
> However my anecdote doesn’t negate what we all see around the internet, so 
> I suppose it can be improved. 
>
> I am a strong -1 on adding words like “dangerously” to the method name. I 
> feel that method names are not the place for warnings like that. I do not 
> like the precedent that it sets for other potentially unsafe methods within 
> the Django codebase, and i believe that it’d result in unnecessarily 
> verbose project code. 
>
> Kye Russell 
> Sent from my iPhone 
>
> > On 19 Feb 2020, at 5:11 pm, Adam Johnson > 
> wrote: 
> > 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e50b75f6-f606-42ed-a2bf-9fd1c1d6afb9%40googlegroups.com.

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

[Kye Russell]

Personally I think that the current name does a fairly good job of conveying 
the effect, and this is coming from someone who doesn’t explicitly understand 
the internal process and is merely inferring it. 

However my anecdote doesn’t negate what we all see around the internet, so I 
suppose it can be improved. 

I am a strong -1 on adding words like “dangerously” to the method name. I feel 
that method names are not the place for warnings like that. I do not like the 
precedent that it sets for other potentially unsafe methods within the Django 
codebase, and i believe that it’d result in unnecessarily verbose project code. 

Kye Russell
Sent from my iPhone

> On 19 Feb 2020, at 5:11 pm, Adam Johnson  wrote:
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ECEDF3F5-2245-4FEA-850E-54FDC43A7891%40kye.id.au.

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

[Josh Smeaton]

My thoughts:

Use and promote a different name that does not make it sound like Django is
making the string safe for you.

Alias the new name to the old names to prevent churn.

Remove all references of the old name from the docs.

What the name should be, meh.

On Thu, 20 Feb 2020 at 03:56, Adam Johnson  wrote:

> Sorry I was a bit keen after a reminder of the thread by Josh Smeaton on
> reddit. I skimmed again and it felt like there was consensus on some kind
> of rename, and it had moved to decision on the name. I guess I'm also sick
> of fixing this in client projects :)
>
> I think your concerns are fair and well-reasoned as always Carlton. You've
> convinced me this isn't worth it.
>
> I'd love to see a bleach "battery" too. Was not aware of html5lib going
> unmaintained - it does highlight that there's a lot to do elsewhere in the
> ecosystem.
>
> On Wed, 19 Feb 2020 at 14:20, Carlton Gibson 
> wrote:
>
>> I've just closed the ticket as wontfix, because I'm not seeing a
>> consensus for the change here. I'm seeing a few Yeahs and a few Mehs.
>> That doesn't mean we can't have it, but the procedure is generally agree
>> here before a ticket.
>> So can I ask, those wanting this, to make the case here, then we can
>> re-open the ticket if there is a general agreement.
>>
>> 
>> FWIW I'm not convinced. The warnings on the mark_safe() docs are pretty
>> clear cut.
>> I think users will just use whatever gets their content on the screen,
>> probably knowing it's not safe, but telling themselves
>> that they'll come back later. Change the names and that will still be the
>> same.
>> There'll just have been a massive load of busywork in between.
>>
>> Ideally we'd just ship Bleach  That's a battery we could include.
>> But we can't really do that, because html5lib is unmaintained, and
>> there's no alternative.
>> Whatever effort there is to be spent on this, I'd rather see it spent
>> there.
>> 
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>> On Wednesday, 19 February 2020 10:11:11 UTC+1, Adam Johnson wrote:
>>>
>>> I made a ticket for this: https://code.djangoproject.com/ticket/31287
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/aa60f3b6-0ace-45fc-9698-6b54e317e091%40googlegroups.com
>> 
>> .
>>
>
>
> --
> Adam
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/AvgxWR-0VrE/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM091w46Pt%3DkiAbU5qgTxOj-_BE5hqz7qZeNNBGkG-RX_A%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAPbDM0f3NKg2YybMu8jjFLeW4KWXcN1ptGqXeSrCSCqH7jr-0g%40mail.gmail.com.

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

[Adam Johnson]

Sorry I was a bit keen after a reminder of the thread by Josh Smeaton on
reddit. I skimmed again and it felt like there was consensus on some kind
of rename, and it had moved to decision on the name. I guess I'm also sick
of fixing this in client projects :)

I think your concerns are fair and well-reasoned as always Carlton. You've
convinced me this isn't worth it.

I'd love to see a bleach "battery" too. Was not aware of html5lib going
unmaintained - it does highlight that there's a lot to do elsewhere in the
ecosystem.

On Wed, 19 Feb 2020 at 14:20, Carlton Gibson 
wrote:

> I've just closed the ticket as wontfix, because I'm not seeing a consensus
> for the change here. I'm seeing a few Yeahs and a few Mehs.
> That doesn't mean we can't have it, but the procedure is generally agree
> here before a ticket.
> So can I ask, those wanting this, to make the case here, then we can
> re-open the ticket if there is a general agreement.
>
> 
> FWIW I'm not convinced. The warnings on the mark_safe() docs are pretty
> clear cut.
> I think users will just use whatever gets their content on the screen,
> probably knowing it's not safe, but telling themselves
> that they'll come back later. Change the names and that will still be the
> same.
> There'll just have been a massive load of busywork in between.
>
> Ideally we'd just ship Bleach  That's a battery we could include.
> But we can't really do that, because html5lib is unmaintained, and there's
> no alternative.
> Whatever effort there is to be spent on this, I'd rather see it spent
> there.
> 
>
> Kind Regards,
>
> Carlton
>
>
> On Wednesday, 19 February 2020 10:11:11 UTC+1, Adam Johnson wrote:
>>
>> I made a ticket for this: https://code.djangoproject.com/ticket/31287
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/aa60f3b6-0ace-45fc-9698-6b54e317e091%40googlegroups.com
> 
> .
>


-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM091w46Pt%3DkiAbU5qgTxOj-_BE5hqz7qZeNNBGkG-RX_A%40mail.gmail.com.

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

[Carlton Gibson]

I've just closed the ticket as wontfix, because I'm not seeing a consensus 
for the change here. I'm seeing a few Yeahs and a few Mehs. 
That doesn't mean we can't have it, but the procedure is generally agree 
here before a ticket. 
So can I ask, those wanting this, to make the case here, then we can 
re-open the ticket if there is a general agreement. 


FWIW I'm not convinced. The warnings on the mark_safe() docs are pretty 
clear cut. 
I think users will just use whatever gets their content on the screen, 
probably knowing it's not safe, but telling themselves 
that they'll come back later. Change the names and that will still be the 
same. 
There'll just have been a massive load of busywork in between. 

Ideally we'd just ship Bleach  That's a battery we could include. 
But we can't really do that, because html5lib is unmaintained, and there's 
no alternative. 
Whatever effort there is to be spent on this, I'd rather see it spent 
there. 


Kind Regards,

Carlton


On Wednesday, 19 February 2020 10:11:11 UTC+1, Adam Johnson wrote:
>
> I made a ticket for this: https://code.djangoproject.com/ticket/31287 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/aa60f3b6-0ace-45fc-9698-6b54e317e091%40googlegroups.com.

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

[Adam Johnson]

I made a ticket for this: https://code.djangoproject.com/ticket/31287

On Fri, 23 Feb 2018 at 08:53, Kamil  wrote:

> The name "mark_safe" unnecessarily exposes an implementation detail.
> People who misunderstand this API probably have no idea how this "marking"
> happens, it would make sense to name this after the *effect* it achieves:
> "don't process / escape me, I've been sanitized somewhere else".
> Any of these would work: "no_escape", "dontescape", "sanitized_elsewhere",
> etc.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/268807b1-cfdf-4bf8-9c02-6e954bfa30e1%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM2qRQYcxKrhN-_n5Quqy-GTRK-1AQeiYGNPMC6Lt5PTDg%40mail.gmail.com.

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

[Kamil]

The name "mark_safe" unnecessarily exposes an implementation detail. People 
who misunderstand this API probably have no idea how this "marking" 
happens, it would make sense to name this after the *effect* it achieves: 
"don't process / escape me, I've been sanitized somewhere else".
Any of these would work: "no_escape", "dontescape", "sanitized_elsewhere", 
etc.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/268807b1-cfdf-4bf8-9c02-6e954bfa30e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

[Josh Smeaton]

We could use the same name or just |trusted.

I'm not so concerned with the `safe` tag as it's already an adjective, but 
I would be ok with an alias for trusted also.

On Friday, 23 February 2018 08:24:50 UTC+11, Florian Apolloner wrote:
>
>
>
> On Thursday, February 22, 2018 at 9:52:04 PM UTC+1, Josh Smeaton wrote:
>>
>> Or, since this isn't a template tag (facepalm) 
>>
>
> Which raises a perfectly valid point: If we were to change this, we will 
> also need to come up with a new name for the "|safe"-filter. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f2a90aa8-87b8-476f-b72e-1b1c2e6fe4e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

[Florian Apolloner]

On Thursday, February 22, 2018 at 9:52:04 PM UTC+1, Josh Smeaton wrote:
>
> Or, since this isn't a template tag (facepalm) 
>

Which raises a perfectly valid point: If we were to change this, we will 
also need to come up with a new name for the "|safe"-filter. 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1aa8a64d-1bea-44d0-bfc0-3139e08ed039%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

[Josh Smeaton]

Or, since this isn't a template tag (facepalm) 

trusted_html(m.content)
trust_html(m.content) 

On Friday, 23 February 2018 07:46:45 UTC+11, Josh Smeaton wrote:
>
> Yes I'm not a fan of the *dangerously...* names either. I'm still 
> somewhat wary of *trust_html* which is a *verb* and could still confuse 
> users in a similar way (does the api make it trustworthy?). I think I'd 
> prefer something more descriptive like *trusted_html*.
>
> {{ content|trusted_html }}
> vs
> {{ content|trust_html }}
>
> On Friday, 23 February 2018 01:07:12 UTC+11, Adam Johnson wrote:
>>
>> I am also in favour of a rename without deprecating the old name.
>>
>> I like 'trust_html' - it's still similarly short but as Tom says it 
>> implies more than 'mark_safe' does.
>>
>> On 22 February 2018 at 08:30, Tom Forbes  wrote:
>>
>>> What about just 'trust_html'? The dangerous part is quite context 
>>> dependent (and a bit of mouth-full), but at the core you are trusting the 
>>> HTML. Hopefully it follows that you should not trust html with user input 
>>> that hasn't been escaped.
>>>
>>>
>>> On 22 Feb 2018 13:10, "Anthony King"  wrote:
>>>
>>> I entirely agree with renaming `mark_safe`. Though it's name is correct, 
>>> it doesn't convey the gravity of what this actually does.
>>> However I'm unsure on the `dangerously_trust_html` name. It wouldn't be 
>>> dangerous to trust the literal "Some Content", for example.
>>>
>>> Perhaps it could be something a bit more explicit. `no_escape(string)`?
>>> This assumes that most have at least heard of escaping.
>>>
>>>
>>> On 22 February 2018 at 12:16, Josh Smeaton  wrote:
>>>
 The concern isn't overusing an API. It's not understanding the proper 
 use case for it.

 "mark safe" can sound like the API is doing sanitation so it can 
 encourage developers to use it incorrectly. I'm fairly sure I've done this 
 myself.

 The intended meaning is "this output is **already** safe" but the name 
 doesn't convey that meaning clearly enough.

 What the proposal is designed to do is convey the "I trust this output" 
 meaning of the API. I'm just wary of enforcing users to change code when 
 they already use the API correctly.

 On Thursday, 22 February 2018 21:08:31 UTC+11, Florian Apolloner wrote:
>
> Yeah, I am also worried about the churn for no gain in my eyes. If 
> users overuse mark_safe, they will overuse dangerously_trust_html too…
>
> On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton 
> wrote:
>>
>> I agree that the names are misleading and we should probably provide 
>> better names. I'm wary of deprecating the old names because it'll create 
>> a 
>> lot of churn (some of which would be the right thing to do). Maybe we 
>> could 
>> just alias and warn when using the old name, leaving a decision on 
>> deprecation until some time in the future.
>>
>> On Monday, 29 January 2018 03:14:27 UTC+11, Stuart Cox wrote:
>>>
>>> In my experience, misuse of mark_safe() — i.e. marking stuff safe 
>>> which *isn’t* actually safe (e.g. HTML from a rich text input) — is 
>>> one of the biggest causes of XSS vulnerabilities in Django projects.
>>>
>>> The docs warn to be careful, but unfortunately I think Django devs 
>>> have just got too used to mark_safe() being *the way* to insert 
>>> HTML in a template. And it’s easy for something that was safe when it 
>>> was 
>>> authored (e.g. calling mark_safe() on a hard-coded string) to be 
>>> copied / repurposed / adapted into a case which is no longer be safe 
>>> (e.g. 
>>> that string replaced with a user-provided value).
>>>
>>> Some other frameworks use scary sounding names to help reinforce 
>>> that there are dangers around similar features, and that this isn’t 
>>> something you should use in everyday work — e.g. React’s 
>>> dangerouslySetInnerHTML.
>>>
>>> Relatedly, this topic 
>>> 
>>>  suggested 
>>> making it more explicit that mark_safe() refers to being safe for 
>>> use in *HTML* contexts (rather than JS, CSS, SQL, etc).
>>>
>>> Combining the two, it would be great if Django could rename 
>>> mark_safe() to dangerously_trust_html(), |safe to 
>>> |dangerously_trust_html, @csrf_exempt to @dangerously_csrf_exempt, 
>>> etc.
>>>
>>> Developers who know what they’re doing with these could then be 
>>> encouraged to create suitable wrappers which handle their use case 
>>> safely 
>>> internally — e.g.:
>>>
>>> @register.filter
>>> def sanitize_and_trust_html(value):
>>> # Safe because we sanitize before trusting
>>> return dangerously_trust_html(bleach.clean(value))
>>>
>>>
>>> -- 
 You 

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

[Tom Forbes]

You're right, trusted_html is a better name than trust_html. I think either
is superior to mark_safe however.

Regarding deprecations, deprecating mark_safe will cause a lot of churn
even if the migration path is as simple as a rename. We should keep the old
alias around for a long time, but promote the new name wherever possible.

On 22 Feb 2018 20:46, "Josh Smeaton"  wrote:

Yes I'm not a fan of the *dangerously...* names either. I'm still somewhat
wary of *trust_html* which is a *verb* and could still confuse users in a
similar way (does the api make it trustworthy?). I think I'd prefer
something more descriptive like *trusted_html*.

{{ content|trusted_html }}
vs
{{ content|trust_html }}


On Friday, 23 February 2018 01:07:12 UTC+11, Adam Johnson wrote:

> I am also in favour of a rename without deprecating the old name.
>
> I like 'trust_html' - it's still similarly short but as Tom says it
> implies more than 'mark_safe' does.
>
> On 22 February 2018 at 08:30, Tom Forbes  wrote:
>
>> What about just 'trust_html'? The dangerous part is quite context
>> dependent (and a bit of mouth-full), but at the core you are trusting the
>> HTML. Hopefully it follows that you should not trust html with user input
>> that hasn't been escaped.
>>
>>
>> On 22 Feb 2018 13:10, "Anthony King"  wrote:
>>
>> I entirely agree with renaming `mark_safe`. Though it's name is correct,
>> it doesn't convey the gravity of what this actually does.
>> However I'm unsure on the `dangerously_trust_html` name. It wouldn't be
>> dangerous to trust the literal "Some Content", for example.
>>
>> Perhaps it could be something a bit more explicit. `no_escape(string)`?
>> This assumes that most have at least heard of escaping.
>>
>>
>> On 22 February 2018 at 12:16, Josh Smeaton  wrote:
>>
>>> The concern isn't overusing an API. It's not understanding the proper
>>> use case for it.
>>>
>>> "mark safe" can sound like the API is doing sanitation so it can
>>> encourage developers to use it incorrectly. I'm fairly sure I've done this
>>> myself.
>>>
>>> The intended meaning is "this output is **already** safe" but the name
>>> doesn't convey that meaning clearly enough.
>>>
>>> What the proposal is designed to do is convey the "I trust this output"
>>> meaning of the API. I'm just wary of enforcing users to change code when
>>> they already use the API correctly.
>>>
>>> On Thursday, 22 February 2018 21:08:31 UTC+11, Florian Apolloner wrote:

 Yeah, I am also worried about the churn for no gain in my eyes. If
 users overuse mark_safe, they will overuse dangerously_trust_html too…

 On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton
 wrote:
>
> I agree that the names are misleading and we should probably provide
> better names. I'm wary of deprecating the old names because it'll create a
> lot of churn (some of which would be the right thing to do). Maybe we 
> could
> just alias and warn when using the old name, leaving a decision on
> deprecation until some time in the future.
>
> On Monday, 29 January 2018 03:14:27 UTC+11, Stuart Cox wrote:
>>
>> In my experience, misuse of mark_safe() — i.e. marking stuff safe
>> which *isn’t* actually safe (e.g. HTML from a rich text input) — is
>> one of the biggest causes of XSS vulnerabilities in Django projects.
>>
>> The docs warn to be careful, but unfortunately I think Django devs
>> have just got too used to mark_safe() being *the way* to insert HTML
>> in a template. And it’s easy for something that was safe when it was
>> authored (e.g. calling mark_safe() on a hard-coded string) to be
>> copied / repurposed / adapted into a case which is no longer be safe 
>> (e.g.
>> that string replaced with a user-provided value).
>>
>> Some other frameworks use scary sounding names to help reinforce that
>> there are dangers around similar features, and that this isn’t something
>> you should use in everyday work — e.g. React’s dangerouslySetInnerHTM
>> L.
>>
>> Relatedly, this topic
>> 
>>  suggested
>> making it more explicit that mark_safe() refers to being safe for
>> use in *HTML* contexts (rather than JS, CSS, SQL, etc).
>>
>> Combining the two, it would be great if Django could rename
>> mark_safe() to dangerously_trust_html(), |safe to
>> |dangerously_trust_html, @csrf_exempt to @dangerously_csrf_exempt,
>> etc.
>>
>> Developers who know what they’re doing with these could then be
>> encouraged to create suitable wrappers which handle their use case safely
>> internally — e.g.:
>>
>> @register.filter
>> def sanitize_and_trust_html(value):
>> # Safe because we sanitize before trusting
>> return 

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

[Josh Smeaton]

Yes I'm not a fan of the *dangerously...* names either. I'm still somewhat 
wary of *trust_html* which is a *verb* and could still confuse users in a 
similar way (does the api make it trustworthy?). I think I'd prefer 
something more descriptive like *trusted_html*.

{{ content|trusted_html }}
vs
{{ content|trust_html }}

On Friday, 23 February 2018 01:07:12 UTC+11, Adam Johnson wrote:
>
> I am also in favour of a rename without deprecating the old name.
>
> I like 'trust_html' - it's still similarly short but as Tom says it 
> implies more than 'mark_safe' does.
>
> On 22 February 2018 at 08:30, Tom Forbes  
> wrote:
>
>> What about just 'trust_html'? The dangerous part is quite context 
>> dependent (and a bit of mouth-full), but at the core you are trusting the 
>> HTML. Hopefully it follows that you should not trust html with user input 
>> that hasn't been escaped.
>>
>>
>> On 22 Feb 2018 13:10, "Anthony King"  
>> wrote:
>>
>> I entirely agree with renaming `mark_safe`. Though it's name is correct, 
>> it doesn't convey the gravity of what this actually does.
>> However I'm unsure on the `dangerously_trust_html` name. It wouldn't be 
>> dangerous to trust the literal "Some Content", for example.
>>
>> Perhaps it could be something a bit more explicit. `no_escape(string)`?
>> This assumes that most have at least heard of escaping.
>>
>>
>> On 22 February 2018 at 12:16, Josh Smeaton > > wrote:
>>
>>> The concern isn't overusing an API. It's not understanding the proper 
>>> use case for it.
>>>
>>> "mark safe" can sound like the API is doing sanitation so it can 
>>> encourage developers to use it incorrectly. I'm fairly sure I've done this 
>>> myself.
>>>
>>> The intended meaning is "this output is **already** safe" but the name 
>>> doesn't convey that meaning clearly enough.
>>>
>>> What the proposal is designed to do is convey the "I trust this output" 
>>> meaning of the API. I'm just wary of enforcing users to change code when 
>>> they already use the API correctly.
>>>
>>> On Thursday, 22 February 2018 21:08:31 UTC+11, Florian Apolloner wrote:

 Yeah, I am also worried about the churn for no gain in my eyes. If 
 users overuse mark_safe, they will overuse dangerously_trust_html too…

 On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton 
 wrote:
>
> I agree that the names are misleading and we should probably provide 
> better names. I'm wary of deprecating the old names because it'll create 
> a 
> lot of churn (some of which would be the right thing to do). Maybe we 
> could 
> just alias and warn when using the old name, leaving a decision on 
> deprecation until some time in the future.
>
> On Monday, 29 January 2018 03:14:27 UTC+11, Stuart Cox wrote:
>>
>> In my experience, misuse of mark_safe() — i.e. marking stuff safe 
>> which *isn’t* actually safe (e.g. HTML from a rich text input) — is 
>> one of the biggest causes of XSS vulnerabilities in Django projects.
>>
>> The docs warn to be careful, but unfortunately I think Django devs 
>> have just got too used to mark_safe() being *the way* to insert HTML 
>> in a template. And it’s easy for something that was safe when it was 
>> authored (e.g. calling mark_safe() on a hard-coded string) to be 
>> copied / repurposed / adapted into a case which is no longer be safe 
>> (e.g. 
>> that string replaced with a user-provided value).
>>
>> Some other frameworks use scary sounding names to help reinforce that 
>> there are dangers around similar features, and that this isn’t something 
>> you should use in everyday work — e.g. React’s 
>> dangerouslySetInnerHTML.
>>
>> Relatedly, this topic 
>> 
>>  suggested 
>> making it more explicit that mark_safe() refers to being safe for 
>> use in *HTML* contexts (rather than JS, CSS, SQL, etc).
>>
>> Combining the two, it would be great if Django could rename 
>> mark_safe() to dangerously_trust_html(), |safe to 
>> |dangerously_trust_html, @csrf_exempt to @dangerously_csrf_exempt, 
>> etc.
>>
>> Developers who know what they’re doing with these could then be 
>> encouraged to create suitable wrappers which handle their use case 
>> safely 
>> internally — e.g.:
>>
>> @register.filter
>> def sanitize_and_trust_html(value):
>> # Safe because we sanitize before trusting
>> return dangerously_trust_html(bleach.clean(value))
>>
>>
>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to django-develop...@googlegroups.com .
>>> To post to 

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

[Дилян Палаузов]

Hello,

is everybody fine with the documentation of mark_safe?

I think by default people don't come to the idea to use mark_safe  
except on occasions, where they notice their output is not the desired  
one.  Then investigations on rendering to achieve the right output  
lead to mark_safe() and by that time the developers have enough  
knowledge how the whole stuff works internally.


With this flow there is no danger of misusing mark_safe.

Greetings
  Дилян

- Message from Douglas Miranda <douglasmirandasi...@gmail.com> -
Date: Thu, 22 Feb 2018 09:40:08 -0800 (PST)
From: Douglas Miranda <douglasmirandasi...@gmail.com>
Reply-To: django-developers@googlegroups.com
 Subject: Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)
  To: "Django developers  (Contributions to Django itself)"  
<django-developers@googlegroups.com>




Yes, people read *mark_safe* as *MAKE_safe*, I'm not sure yet, but I'm
liking the idea of *trust_html*, I feel like more developers will
understand what they're doing.

Maybe the docs could have more detailed notes about HTML inputs that you
want to mark them safe, one thing is trust "" another is trust "{{
post.content }}". Rich text editors play a big part of beginner devs, a lot
of people start with Django and don't quite understand Python or Web
Security yet, that's just reality.

Django it is not to blame, but I think that's a small change with big
impact.


On Thursday, February 22, 2018 at 10:07:12 AM UTC-4, Adam Johnson wrote:


I am also in favour of a rename without deprecating the old name.

I like 'trust_html' - it's still similarly short but as Tom says it
implies more than 'mark_safe' does.

On 22 February 2018 at 08:30, Tom Forbes <t...@tomforb.es >
wrote:


What about just 'trust_html'? The dangerous part is quite context
dependent (and a bit of mouth-full), but at the core you are trusting the
HTML. Hopefully it follows that you should not trust html with user input
that hasn't been escaped.


On 22 Feb 2018 13:10, "Anthony King" <anthon...@gmail.com >
wrote:

I entirely agree with renaming `mark_safe`. Though it's name is correct,
it doesn't convey the gravity of what this actually does.
However I'm unsure on the `dangerously_trust_html` name. It wouldn't be
dangerous to trust the literal "Some Content", for example.

Perhaps it could be something a bit more explicit. `no_escape(string)`?
This assumes that most have at least heard of escaping.


On 22 February 2018 at 12:16, Josh Smeaton <josh.s...@gmail.com
> wrote:


The concern isn't overusing an API. It's not understanding the proper
use case for it.

"mark safe" can sound like the API is doing sanitation so it can
encourage developers to use it incorrectly. I'm fairly sure I've done this
myself.

The intended meaning is "this output is **already** safe" but the name
doesn't convey that meaning clearly enough.

What the proposal is designed to do is convey the "I trust this output"
meaning of the API. I'm just wary of enforcing users to change code when
they already use the API correctly.

On Thursday, 22 February 2018 21:08:31 UTC+11, Florian Apolloner wrote:


Yeah, I am also worried about the churn for no gain in my eyes. If
users overuse mark_safe, they will overuse dangerously_trust_html too…

On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton
wrote:


I agree that the names are misleading and we should probably provide
better names. I'm wary of deprecating the old names because  
it'll create a
lot of churn (some of which would be the right thing to do).  
Maybe we could

just alias and warn when using the old name, leaving a decision on
deprecation until some time in the future.

On Monday, 29 January 2018 03:14:27 UTC+11, Stuart Cox wrote:


In my experience, misuse of mark_safe() — i.e. marking stuff safe
which *isn’t* actually safe (e.g. HTML from a rich text input) — is
one of the biggest causes of XSS vulnerabilities in Django projects.

The docs warn to be careful, but unfortunately I think Django devs
have just got too used to mark_safe() being *the way* to insert HTML
in a template. And it’s easy for something that was safe when it was
authored (e.g. calling mark_safe() on a hard-coded string) to be
copied / repurposed / adapted into a case which is no longer  
be safe (e.g.

that string replaced with a user-provided value).

Some other frameworks use scary sounding names to help reinforce that
there are dangers around similar features, and that this isn’t  
something

you should use in everyday work — e.g. React’s
dangerouslySetInnerHTML.

Relatedly, this topic
<https://groups.google.com/d/msg/django-developers/c4fa2pOcHxo/EtT942WnyiAJ>  
suggested

making it more explicit that mark_safe() refers to being safe for
use in *HTML* contexts (rather than JS, CSS, SQL, etc).

Combining the two, it wou

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

[Douglas Miranda]

Yes, people read *mark_safe* as *MAKE_safe*, I'm not sure yet, but I'm 
liking the idea of *trust_html*, I feel like more developers will 
understand what they're doing.

Maybe the docs could have more detailed notes about HTML inputs that you 
want to mark them safe, one thing is trust "" another is trust "{{ 
post.content }}". Rich text editors play a big part of beginner devs, a lot 
of people start with Django and don't quite understand Python or Web 
Security yet, that's just reality.

Django it is not to blame, but I think that's a small change with big 
impact.


On Thursday, February 22, 2018 at 10:07:12 AM UTC-4, Adam Johnson wrote:
>
> I am also in favour of a rename without deprecating the old name.
>
> I like 'trust_html' - it's still similarly short but as Tom says it 
> implies more than 'mark_safe' does.
>
> On 22 February 2018 at 08:30, Tom Forbes  
> wrote:
>
>> What about just 'trust_html'? The dangerous part is quite context 
>> dependent (and a bit of mouth-full), but at the core you are trusting the 
>> HTML. Hopefully it follows that you should not trust html with user input 
>> that hasn't been escaped.
>>
>>
>> On 22 Feb 2018 13:10, "Anthony King"  
>> wrote:
>>
>> I entirely agree with renaming `mark_safe`. Though it's name is correct, 
>> it doesn't convey the gravity of what this actually does.
>> However I'm unsure on the `dangerously_trust_html` name. It wouldn't be 
>> dangerous to trust the literal "Some Content", for example.
>>
>> Perhaps it could be something a bit more explicit. `no_escape(string)`?
>> This assumes that most have at least heard of escaping.
>>
>>
>> On 22 February 2018 at 12:16, Josh Smeaton > > wrote:
>>
>>> The concern isn't overusing an API. It's not understanding the proper 
>>> use case for it.
>>>
>>> "mark safe" can sound like the API is doing sanitation so it can 
>>> encourage developers to use it incorrectly. I'm fairly sure I've done this 
>>> myself.
>>>
>>> The intended meaning is "this output is **already** safe" but the name 
>>> doesn't convey that meaning clearly enough.
>>>
>>> What the proposal is designed to do is convey the "I trust this output" 
>>> meaning of the API. I'm just wary of enforcing users to change code when 
>>> they already use the API correctly.
>>>
>>> On Thursday, 22 February 2018 21:08:31 UTC+11, Florian Apolloner wrote:

 Yeah, I am also worried about the churn for no gain in my eyes. If 
 users overuse mark_safe, they will overuse dangerously_trust_html too…

 On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton 
 wrote:
>
> I agree that the names are misleading and we should probably provide 
> better names. I'm wary of deprecating the old names because it'll create 
> a 
> lot of churn (some of which would be the right thing to do). Maybe we 
> could 
> just alias and warn when using the old name, leaving a decision on 
> deprecation until some time in the future.
>
> On Monday, 29 January 2018 03:14:27 UTC+11, Stuart Cox wrote:
>>
>> In my experience, misuse of mark_safe() — i.e. marking stuff safe 
>> which *isn’t* actually safe (e.g. HTML from a rich text input) — is 
>> one of the biggest causes of XSS vulnerabilities in Django projects.
>>
>> The docs warn to be careful, but unfortunately I think Django devs 
>> have just got too used to mark_safe() being *the way* to insert HTML 
>> in a template. And it’s easy for something that was safe when it was 
>> authored (e.g. calling mark_safe() on a hard-coded string) to be 
>> copied / repurposed / adapted into a case which is no longer be safe 
>> (e.g. 
>> that string replaced with a user-provided value).
>>
>> Some other frameworks use scary sounding names to help reinforce that 
>> there are dangers around similar features, and that this isn’t something 
>> you should use in everyday work — e.g. React’s 
>> dangerouslySetInnerHTML.
>>
>> Relatedly, this topic 
>> 
>>  suggested 
>> making it more explicit that mark_safe() refers to being safe for 
>> use in *HTML* contexts (rather than JS, CSS, SQL, etc).
>>
>> Combining the two, it would be great if Django could rename 
>> mark_safe() to dangerously_trust_html(), |safe to 
>> |dangerously_trust_html, @csrf_exempt to @dangerously_csrf_exempt, 
>> etc.
>>
>> Developers who know what they’re doing with these could then be 
>> encouraged to create suitable wrappers which handle their use case 
>> safely 
>> internally — e.g.:
>>
>> @register.filter
>> def sanitize_and_trust_html(value):
>> # Safe because we sanitize before trusting
>> return dangerously_trust_html(bleach.clean(value))
>>
>>
>> -- 
>>> You received this message 

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

[Adam Johnson]

I am also in favour of a rename without deprecating the old name.

I like 'trust_html' - it's still similarly short but as Tom says it implies
more than 'mark_safe' does.

On 22 February 2018 at 08:30, Tom Forbes  wrote:

> What about just 'trust_html'? The dangerous part is quite context
> dependent (and a bit of mouth-full), but at the core you are trusting the
> HTML. Hopefully it follows that you should not trust html with user input
> that hasn't been escaped.
>
>
> On 22 Feb 2018 13:10, "Anthony King"  wrote:
>
> I entirely agree with renaming `mark_safe`. Though it's name is correct,
> it doesn't convey the gravity of what this actually does.
> However I'm unsure on the `dangerously_trust_html` name. It wouldn't be
> dangerous to trust the literal "Some Content", for example.
>
> Perhaps it could be something a bit more explicit. `no_escape(string)`?
> This assumes that most have at least heard of escaping.
>
>
> On 22 February 2018 at 12:16, Josh Smeaton  wrote:
>
>> The concern isn't overusing an API. It's not understanding the proper use
>> case for it.
>>
>> "mark safe" can sound like the API is doing sanitation so it can
>> encourage developers to use it incorrectly. I'm fairly sure I've done this
>> myself.
>>
>> The intended meaning is "this output is **already** safe" but the name
>> doesn't convey that meaning clearly enough.
>>
>> What the proposal is designed to do is convey the "I trust this output"
>> meaning of the API. I'm just wary of enforcing users to change code when
>> they already use the API correctly.
>>
>> On Thursday, 22 February 2018 21:08:31 UTC+11, Florian Apolloner wrote:
>>>
>>> Yeah, I am also worried about the churn for no gain in my eyes. If users
>>> overuse mark_safe, they will overuse dangerously_trust_html too…
>>>
>>> On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton wrote:

 I agree that the names are misleading and we should probably provide
 better names. I'm wary of deprecating the old names because it'll create a
 lot of churn (some of which would be the right thing to do). Maybe we could
 just alias and warn when using the old name, leaving a decision on
 deprecation until some time in the future.

 On Monday, 29 January 2018 03:14:27 UTC+11, Stuart Cox wrote:
>
> In my experience, misuse of mark_safe() — i.e. marking stuff safe
> which *isn’t* actually safe (e.g. HTML from a rich text input) — is
> one of the biggest causes of XSS vulnerabilities in Django projects.
>
> The docs warn to be careful, but unfortunately I think Django devs
> have just got too used to mark_safe() being *the way* to insert HTML
> in a template. And it’s easy for something that was safe when it was
> authored (e.g. calling mark_safe() on a hard-coded string) to be
> copied / repurposed / adapted into a case which is no longer be safe (e.g.
> that string replaced with a user-provided value).
>
> Some other frameworks use scary sounding names to help reinforce that
> there are dangers around similar features, and that this isn’t something
> you should use in everyday work — e.g. React’s dangerouslySetInnerHTML
> .
>
> Relatedly, this topic
> 
>  suggested
> making it more explicit that mark_safe() refers to being safe for use
> in *HTML* contexts (rather than JS, CSS, SQL, etc).
>
> Combining the two, it would be great if Django could rename
> mark_safe() to dangerously_trust_html(), |safe to
> |dangerously_trust_html, @csrf_exempt to @dangerously_csrf_exempt,
> etc.
>
> Developers who know what they’re doing with these could then be
> encouraged to create suitable wrappers which handle their use case safely
> internally — e.g.:
>
> @register.filter
> def sanitize_and_trust_html(value):
> # Safe because we sanitize before trusting
> return dangerously_trust_html(bleach.clean(value))
>
>
> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/django-developers/db4ac958-89e1-4286-a616-99e9854c9bbb%4
>> 0googlegroups.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are 

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

[Tom Forbes]

What about just 'trust_html'? The dangerous part is quite context dependent
(and a bit of mouth-full), but at the core you are trusting the HTML.
Hopefully it follows that you should not trust html with user input that
hasn't been escaped.

On 22 Feb 2018 13:10, "Anthony King"  wrote:

I entirely agree with renaming `mark_safe`. Though it's name is correct, it
doesn't convey the gravity of what this actually does.
However I'm unsure on the `dangerously_trust_html` name. It wouldn't be
dangerous to trust the literal "Some Content", for example.

Perhaps it could be something a bit more explicit. `no_escape(string)`?
This assumes that most have at least heard of escaping.


On 22 February 2018 at 12:16, Josh Smeaton  wrote:

> The concern isn't overusing an API. It's not understanding the proper use
> case for it.
>
> "mark safe" can sound like the API is doing sanitation so it can encourage
> developers to use it incorrectly. I'm fairly sure I've done this myself.
>
> The intended meaning is "this output is **already** safe" but the name
> doesn't convey that meaning clearly enough.
>
> What the proposal is designed to do is convey the "I trust this output"
> meaning of the API. I'm just wary of enforcing users to change code when
> they already use the API correctly.
>
> On Thursday, 22 February 2018 21:08:31 UTC+11, Florian Apolloner wrote:
>>
>> Yeah, I am also worried about the churn for no gain in my eyes. If users
>> overuse mark_safe, they will overuse dangerously_trust_html too…
>>
>> On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton wrote:
>>>
>>> I agree that the names are misleading and we should probably provide
>>> better names. I'm wary of deprecating the old names because it'll create a
>>> lot of churn (some of which would be the right thing to do). Maybe we could
>>> just alias and warn when using the old name, leaving a decision on
>>> deprecation until some time in the future.
>>>
>>> On Monday, 29 January 2018 03:14:27 UTC+11, Stuart Cox wrote:

 In my experience, misuse of mark_safe() — i.e. marking stuff safe
 which *isn’t* actually safe (e.g. HTML from a rich text input) — is
 one of the biggest causes of XSS vulnerabilities in Django projects.

 The docs warn to be careful, but unfortunately I think Django devs have
 just got too used to mark_safe() being *the way* to insert HTML in a
 template. And it’s easy for something that was safe when it was authored
 (e.g. calling mark_safe() on a hard-coded string) to be copied /
 repurposed / adapted into a case which is no longer be safe (e.g. that
 string replaced with a user-provided value).

 Some other frameworks use scary sounding names to help reinforce that
 there are dangers around similar features, and that this isn’t something
 you should use in everyday work — e.g. React’s dangerouslySetInnerHTML.

 Relatedly, this topic
 
  suggested
 making it more explicit that mark_safe() refers to being safe for use
 in *HTML* contexts (rather than JS, CSS, SQL, etc).

 Combining the two, it would be great if Django could rename mark_safe() to
 dangerously_trust_html(), |safe to |dangerously_trust_html,
 @csrf_exempt to @dangerously_csrf_exempt, etc.

 Developers who know what they’re doing with these could then be
 encouraged to create suitable wrappers which handle their use case safely
 internally — e.g.:

 @register.filter
 def sanitize_and_trust_html(value):
 # Safe because we sanitize before trusting
 return dangerously_trust_html(bleach.clean(value))


 --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/ms
> gid/django-developers/db4ac958-89e1-4286-a616-99e9854c9bbb%
> 40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To 

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

[Anthony King]

I entirely agree with renaming `mark_safe`. Though it's name is correct, it
doesn't convey the gravity of what this actually does.
However I'm unsure on the `dangerously_trust_html` name. It wouldn't be
dangerous to trust the literal "Some Content", for example.

Perhaps it could be something a bit more explicit. `no_escape(string)`?
This assumes that most have at least heard of escaping.


On 22 February 2018 at 12:16, Josh Smeaton  wrote:

> The concern isn't overusing an API. It's not understanding the proper use
> case for it.
>
> "mark safe" can sound like the API is doing sanitation so it can encourage
> developers to use it incorrectly. I'm fairly sure I've done this myself.
>
> The intended meaning is "this output is **already** safe" but the name
> doesn't convey that meaning clearly enough.
>
> What the proposal is designed to do is convey the "I trust this output"
> meaning of the API. I'm just wary of enforcing users to change code when
> they already use the API correctly.
>
> On Thursday, 22 February 2018 21:08:31 UTC+11, Florian Apolloner wrote:
>>
>> Yeah, I am also worried about the churn for no gain in my eyes. If users
>> overuse mark_safe, they will overuse dangerously_trust_html too…
>>
>> On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton wrote:
>>>
>>> I agree that the names are misleading and we should probably provide
>>> better names. I'm wary of deprecating the old names because it'll create a
>>> lot of churn (some of which would be the right thing to do). Maybe we could
>>> just alias and warn when using the old name, leaving a decision on
>>> deprecation until some time in the future.
>>>
>>> On Monday, 29 January 2018 03:14:27 UTC+11, Stuart Cox wrote:

 In my experience, misuse of mark_safe() — i.e. marking stuff safe
 which *isn’t* actually safe (e.g. HTML from a rich text input) — is
 one of the biggest causes of XSS vulnerabilities in Django projects.

 The docs warn to be careful, but unfortunately I think Django devs have
 just got too used to mark_safe() being *the way* to insert HTML in a
 template. And it’s easy for something that was safe when it was authored
 (e.g. calling mark_safe() on a hard-coded string) to be copied /
 repurposed / adapted into a case which is no longer be safe (e.g. that
 string replaced with a user-provided value).

 Some other frameworks use scary sounding names to help reinforce that
 there are dangers around similar features, and that this isn’t something
 you should use in everyday work — e.g. React’s dangerouslySetInnerHTML.

 Relatedly, this topic
 
  suggested
 making it more explicit that mark_safe() refers to being safe for use
 in *HTML* contexts (rather than JS, CSS, SQL, etc).

 Combining the two, it would be great if Django could rename mark_safe() to
 dangerously_trust_html(), |safe to |dangerously_trust_html,
 @csrf_exempt to @dangerously_csrf_exempt, etc.

 Developers who know what they’re doing with these could then be
 encouraged to create suitable wrappers which handle their use case safely
 internally — e.g.:

 @register.filter
 def sanitize_and_trust_html(value):
 # Safe because we sanitize before trusting
 return dangerously_trust_html(bleach.clean(value))


 --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/db4ac958-89e1-4286-a616-
> 99e9854c9bbb%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALs0z1YuC63d6aJ1VEhcnezpCg1NPJYpadcR4-fRRwGDrR4-qw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

[Tim Graham]

I don't know that "dangerously_trust_html" is a better name. The argument 
is supposed to be a string that you know is trusted so there shouldn't be 
any danger involved. Naming something based on how it could be misused 
seems odd.

For me, mark_safe() is a fine name, but maybe that preference is from a 
knowledge of django.utils.safestring internals that most users don't have.

On Thursday, February 22, 2018 at 7:16:29 AM UTC-5, Josh Smeaton wrote:
>
> The concern isn't overusing an API. It's not understanding the proper use 
> case for it.
>
> "mark safe" can sound like the API is doing sanitation so it can encourage 
> developers to use it incorrectly. I'm fairly sure I've done this myself.
>
> The intended meaning is "this output is **already** safe" but the name 
> doesn't convey that meaning clearly enough.
>
> What the proposal is designed to do is convey the "I trust this output" 
> meaning of the API. I'm just wary of enforcing users to change code when 
> they already use the API correctly.
>
> On Thursday, 22 February 2018 21:08:31 UTC+11, Florian Apolloner wrote:
>>
>> Yeah, I am also worried about the churn for no gain in my eyes. If users 
>> overuse mark_safe, they will overuse dangerously_trust_html too…
>>
>> On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton wrote:
>>>
>>> I agree that the names are misleading and we should probably provide 
>>> better names. I'm wary of deprecating the old names because it'll create a 
>>> lot of churn (some of which would be the right thing to do). Maybe we could 
>>> just alias and warn when using the old name, leaving a decision on 
>>> deprecation until some time in the future.
>>>
>>> On Monday, 29 January 2018 03:14:27 UTC+11, Stuart Cox wrote:

 In my experience, misuse of mark_safe() — i.e. marking stuff safe 
 which *isn’t* actually safe (e.g. HTML from a rich text input) — is 
 one of the biggest causes of XSS vulnerabilities in Django projects.

 The docs warn to be careful, but unfortunately I think Django devs have 
 just got too used to mark_safe() being *the way* to insert HTML in a 
 template. And it’s easy for something that was safe when it was authored 
 (e.g. calling mark_safe() on a hard-coded string) to be copied / 
 repurposed / adapted into a case which is no longer be safe (e.g. that 
 string replaced with a user-provided value).

 Some other frameworks use scary sounding names to help reinforce that 
 there are dangers around similar features, and that this isn’t something 
 you should use in everyday work — e.g. React’s dangerouslySetInnerHTML.

 Relatedly, this topic 
 
  suggested 
 making it more explicit that mark_safe() refers to being safe for use 
 in *HTML* contexts (rather than JS, CSS, SQL, etc).

 Combining the two, it would be great if Django could rename mark_safe() to 
 dangerously_trust_html(), |safe to |dangerously_trust_html, 
 @csrf_exempt to @dangerously_csrf_exempt, etc.

 Developers who know what they’re doing with these could then be 
 encouraged to create suitable wrappers which handle their use case safely 
 internally — e.g.:

 @register.filter
 def sanitize_and_trust_html(value):
 # Safe because we sanitize before trusting
 return dangerously_trust_html(bleach.clean(value))




-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/370611c1-2031-4c0b-9f56-4b2c482e1113%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

[Josh Smeaton]

The concern isn't overusing an API. It's not understanding the proper use 
case for it.

"mark safe" can sound like the API is doing sanitation so it can encourage 
developers to use it incorrectly. I'm fairly sure I've done this myself.

The intended meaning is "this output is **already** safe" but the name 
doesn't convey that meaning clearly enough.

What the proposal is designed to do is convey the "I trust this output" 
meaning of the API. I'm just wary of enforcing users to change code when 
they already use the API correctly.

On Thursday, 22 February 2018 21:08:31 UTC+11, Florian Apolloner wrote:
>
> Yeah, I am also worried about the churn for no gain in my eyes. If users 
> overuse mark_safe, they will overuse dangerously_trust_html too…
>
> On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton wrote:
>>
>> I agree that the names are misleading and we should probably provide 
>> better names. I'm wary of deprecating the old names because it'll create a 
>> lot of churn (some of which would be the right thing to do). Maybe we could 
>> just alias and warn when using the old name, leaving a decision on 
>> deprecation until some time in the future.
>>
>> On Monday, 29 January 2018 03:14:27 UTC+11, Stuart Cox wrote:
>>>
>>> In my experience, misuse of mark_safe() — i.e. marking stuff safe which 
>>> *isn’t* actually safe (e.g. HTML from a rich text input) — is one of 
>>> the biggest causes of XSS vulnerabilities in Django projects.
>>>
>>> The docs warn to be careful, but unfortunately I think Django devs have 
>>> just got too used to mark_safe() being *the way* to insert HTML in a 
>>> template. And it’s easy for something that was safe when it was authored 
>>> (e.g. calling mark_safe() on a hard-coded string) to be copied / 
>>> repurposed / adapted into a case which is no longer be safe (e.g. that 
>>> string replaced with a user-provided value).
>>>
>>> Some other frameworks use scary sounding names to help reinforce that 
>>> there are dangers around similar features, and that this isn’t something 
>>> you should use in everyday work — e.g. React’s dangerouslySetInnerHTML.
>>>
>>> Relatedly, this topic 
>>> 
>>>  suggested 
>>> making it more explicit that mark_safe() refers to being safe for use 
>>> in *HTML* contexts (rather than JS, CSS, SQL, etc).
>>>
>>> Combining the two, it would be great if Django could rename mark_safe() to 
>>> dangerously_trust_html(), |safe to |dangerously_trust_html, @csrf_exempt to 
>>> @dangerously_csrf_exempt, etc.
>>>
>>> Developers who know what they’re doing with these could then be 
>>> encouraged to create suitable wrappers which handle their use case safely 
>>> internally — e.g.:
>>>
>>> @register.filter
>>> def sanitize_and_trust_html(value):
>>> # Safe because we sanitize before trusting
>>> return dangerously_trust_html(bleach.clean(value))
>>>
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/db4ac958-89e1-4286-a616-99e9854c9bbb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

[Florian Apolloner]

Yeah, I am also worried about the churn for no gain in my eyes. If users 
overuse mark_safe, they will overuse dangerously_trust_html too…

On Wednesday, February 21, 2018 at 10:41:15 PM UTC+1, Josh Smeaton wrote:
>
> I agree that the names are misleading and we should probably provide 
> better names. I'm wary of deprecating the old names because it'll create a 
> lot of churn (some of which would be the right thing to do). Maybe we could 
> just alias and warn when using the old name, leaving a decision on 
> deprecation until some time in the future.
>
> On Monday, 29 January 2018 03:14:27 UTC+11, Stuart Cox wrote:
>>
>> In my experience, misuse of mark_safe() — i.e. marking stuff safe which 
>> *isn’t* actually safe (e.g. HTML from a rich text input) — is one of the 
>> biggest causes of XSS vulnerabilities in Django projects.
>>
>> The docs warn to be careful, but unfortunately I think Django devs have 
>> just got too used to mark_safe() being *the way* to insert HTML in a 
>> template. And it’s easy for something that was safe when it was authored 
>> (e.g. calling mark_safe() on a hard-coded string) to be copied / 
>> repurposed / adapted into a case which is no longer be safe (e.g. that 
>> string replaced with a user-provided value).
>>
>> Some other frameworks use scary sounding names to help reinforce that 
>> there are dangers around similar features, and that this isn’t something 
>> you should use in everyday work — e.g. React’s dangerouslySetInnerHTML.
>>
>> Relatedly, this topic 
>>  
>> suggested 
>> making it more explicit that mark_safe() refers to being safe for use in 
>> *HTML* contexts (rather than JS, CSS, SQL, etc).
>>
>> Combining the two, it would be great if Django could rename mark_safe() to 
>> dangerously_trust_html(), |safe to |dangerously_trust_html, @csrf_exempt to 
>> @dangerously_csrf_exempt, etc.
>>
>> Developers who know what they’re doing with these could then be 
>> encouraged to create suitable wrappers which handle their use case safely 
>> internally — e.g.:
>>
>> @register.filter
>> def sanitize_and_trust_html(value):
>> # Safe because we sanitize before trusting
>> return dangerously_trust_html(bleach.clean(value))
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3d683e14-a2dd-4f17-8774-9ddd88558254%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

[Collin Anderson]

> Maybe we could just alias and warn when using the old name, leaving a
decision on deprecation until some time in the future.

I'm a fan of delaying deprecation/removal if we do change it. :)

On Wed, Feb 21, 2018 at 4:41 PM, Josh Smeaton 
wrote:

> I agree that the names are misleading and we should probably provide
> better names. I'm wary of deprecating the old names because it'll create a
> lot of churn (some of which would be the right thing to do). Maybe we could
> just alias and warn when using the old name, leaving a decision on
> deprecation until some time in the future.
>
> On Monday, 29 January 2018 03:14:27 UTC+11, Stuart Cox wrote:
>>
>> In my experience, misuse of mark_safe() — i.e. marking stuff safe which
>> *isn’t* actually safe (e.g. HTML from a rich text input) — is one of the
>> biggest causes of XSS vulnerabilities in Django projects.
>>
>> The docs warn to be careful, but unfortunately I think Django devs have
>> just got too used to mark_safe() being *the way* to insert HTML in a
>> template. And it’s easy for something that was safe when it was authored
>> (e.g. calling mark_safe() on a hard-coded string) to be copied /
>> repurposed / adapted into a case which is no longer be safe (e.g. that
>> string replaced with a user-provided value).
>>
>> Some other frameworks use scary sounding names to help reinforce that
>> there are dangers around similar features, and that this isn’t something
>> you should use in everyday work — e.g. React’s dangerouslySetInnerHTML.
>>
>> Relatedly, this topic
>>  
>> suggested
>> making it more explicit that mark_safe() refers to being safe for use in
>> *HTML* contexts (rather than JS, CSS, SQL, etc).
>>
>> Combining the two, it would be great if Django could rename mark_safe() to
>> dangerously_trust_html(), |safe to |dangerously_trust_html, @csrf_exempt to
>> @dangerously_csrf_exempt, etc.
>>
>> Developers who know what they’re doing with these could then be
>> encouraged to create suitable wrappers which handle their use case safely
>> internally — e.g.:
>>
>> @register.filter
>> def sanitize_and_trust_html(value):
>> # Safe because we sanitize before trusting
>> return dangerously_trust_html(bleach.clean(value))
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/05de4602-5c44-41bf-b675-
> ab15d69fb46d%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFO84S7x0y07eY4uYO2cKCe4%2B8jo9x%3DrO0QA3EAbJvU1pmbJ5Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

[Josh Smeaton]

I agree that the names are misleading and we should probably provide better 
names. I'm wary of deprecating the old names because it'll create a lot of 
churn (some of which would be the right thing to do). Maybe we could just 
alias and warn when using the old name, leaving a decision on deprecation 
until some time in the future.

On Monday, 29 January 2018 03:14:27 UTC+11, Stuart Cox wrote:
>
> In my experience, misuse of mark_safe() — i.e. marking stuff safe which 
> *isn’t* actually safe (e.g. HTML from a rich text input) — is one of the 
> biggest causes of XSS vulnerabilities in Django projects.
>
> The docs warn to be careful, but unfortunately I think Django devs have 
> just got too used to mark_safe() being *the way* to insert HTML in a 
> template. And it’s easy for something that was safe when it was authored 
> (e.g. calling mark_safe() on a hard-coded string) to be copied / 
> repurposed / adapted into a case which is no longer be safe (e.g. that 
> string replaced with a user-provided value).
>
> Some other frameworks use scary sounding names to help reinforce that 
> there are dangers around similar features, and that this isn’t something 
> you should use in everyday work — e.g. React’s dangerouslySetInnerHTML.
>
> Relatedly, this topic 
>  
> suggested 
> making it more explicit that mark_safe() refers to being safe for use in 
> *HTML* contexts (rather than JS, CSS, SQL, etc).
>
> Combining the two, it would be great if Django could rename mark_safe() to 
> dangerously_trust_html(), |safe to |dangerously_trust_html, @csrf_exempt to 
> @dangerously_csrf_exempt, etc.
>
> Developers who know what they’re doing with these could then be encouraged 
> to create suitable wrappers which handle their use case safely internally — 
> e.g.:
>
> @register.filter
> def sanitize_and_trust_html(value):
> # Safe because we sanitize before trusting
> return dangerously_trust_html(bleach.clean(value))
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/05de4602-5c44-41bf-b675-ab15d69fb46d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)

[Douglas Miranda]

I think this can mislead the developers to think mark_safe solves it all.

The forums are full of answers with *Use mark_safe;* *Use htmlfield|safe;* 
 
Maybe Django should start warning about mark_safe on the logs, then change 
the behavior. (Or even deprecate and remove)

Things like this we tend to blame the users, but it's there for using and 
it says *"SAFE"*.


On Sunday, January 28, 2018 at 1:14:27 PM UTC-3, Stuart Cox wrote:
>
> In my experience, misuse of mark_safe() — i.e. marking stuff safe which 
> *isn’t* actually safe (e.g. HTML from a rich text input) — is one of the 
> biggest causes of XSS vulnerabilities in Django projects.
>
> The docs warn to be careful, but unfortunately I think Django devs have 
> just got too used to mark_safe() being *the way* to insert HTML in a 
> template. And it’s easy for something that was safe when it was authored 
> (e.g. calling mark_safe() on a hard-coded string) to be copied / 
> repurposed / adapted into a case which is no longer be safe (e.g. that 
> string replaced with a user-provided value).
>
> Some other frameworks use scary sounding names to help reinforce that 
> there are dangers around similar features, and that this isn’t something 
> you should use in everyday work — e.g. React’s dangerouslySetInnerHTML.
>
> Relatedly, this topic 
>  
> suggested 
> making it more explicit that mark_safe() refers to being safe for use in 
> *HTML* contexts (rather than JS, CSS, SQL, etc).
>
> Combining the two, it would be great if Django could rename mark_safe() to 
> dangerously_trust_html(), |safe to |dangerously_trust_html, @csrf_exempt to 
> @dangerously_csrf_exempt, etc.
>
> Developers who know what they’re doing with these could then be encouraged 
> to create suitable wrappers which handle their use case safely internally — 
> e.g.:
>
> @register.filter
> def sanitize_and_trust_html(value):
> # Safe because we sanitize before trusting
> return dangerously_trust_html(bleach.clean(value))
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c4da4fc8-6565-42d8-bb4a-d9a8601ae355%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.