Re-work Privacy & Security Considerations

[benfrancis]

I propose:

• Moving Privacy Considerations and Security Considerations sections to the top level of the document, at the end, as is normal for W3C specifications
• Removing section 7.2.8.4 Transport security since all of the feedback on the PR seemed to be not to include it
• Instead add some text to Security Considerations to recommend following best practices from the WoT Security Best Practices document, as suggested by @mmccool

I can provide a PR.

Note: From GitHub it appears that #87 and #206 were merged without review. I assume there is a good reason for that, but if a decision is made during a meeting to merge a PR, it would be great if whoever merges it leaves a note to that effect before merging, so we don't have to trawl through meeting notes to figure out if a pull request was merged in error. It looks really odd when all the review comments say not to merge something and then it's merged anyway, so it would be good to explain why the decision contradicted the feedback provided.

[benfrancis]

Note that a reference was added to the security best practices document in #124, but it should probably be moved to the new security considerations section as part of this issue.

[mlagally]

@benfrancis

Note: From GitHub it appears that #87 and #206 were merged without review. I assume there is a good reason for that, but if a decision is made during a meeting to merge a PR, it would be great if whoever merges it leaves a note to that effect before merging, so we don't have to trawl through meeting notes to figure out if a pull request was merged in error. It looks really odd when all the review comments say not to merge something and then it's merged anyway, so it would be good to explain why the decision contradicted the feedback provided.

Can you please elaborate your comment? I may have misunderstood, but I don't see any comments in #87 or #206 that raise any concern with the proposed text. What is your specific concern here?
We are reviewing all PRs in our weekly calls among all participants, so it is very unlikely that something is merged by "error".

[benfrancis]

What is your specific concern here?

To be clear I am not suggesting any wrong doing, just suggesting better record keeping to avoid misunderstandings.

For #87:

• The consensus of the discussion appears to be that we can not mandate TLS, and should instead defer to the Security Best Practices document which already recommends it. This would mean no need for a Transport Security section, just some brief text in the Security Considerations section, which should be at the top level of the document. I've suggested a fix for that in this issue.
• There are no code review approvals or written record of the decision to merge the PR.

For #206:

• The name of the PR says it adds a Security + privacy section, but it also adds a new HTTP Profiles section, which broke the structure of the document and created some new concerns, see Wrong sections/headers for HTTP profiles #214 and Removing HTTP Profile Specification mention #244. I've created a PR to fix the broken HTML in Fix indentation and missing </section> tag - closes #214 #249 and suggested further changes to the structure to accommodate this new section in Wrong sections/headers for HTTP profiles #214 (comment)
• There are no code review approvals or written record of the decision to merge the PR.