Re: [whatwg/dom] What is the "security policy" for adding new events and elements to the Web Platform? (#913)

> What is the "security policy" for adding new events and elements to the Web Platform?

Where there is a trade-off between new features and security:

From the side bench:

### 1. Outdated user agents must NOT be considered at all.

Reason: Otherwise there will not be stable progress.

Explanation: Existing obsoleteware is foremost the fault of the 3 big vendors as they don't force the software to be updated xor uninstalled (after a grace period of not updating such as 3 months) by default. Second to that it is the responsbility of the user. Example: If I use dual-wire-electricity it is not the fault of a lamp producer if I hurt myself in case the lamp comes with all the security feautres that are recent.

### 2. User privacy is the most relevant security feature and stands above all

Reason: Users need to feel save and trust the platform, otherwise they will move to walled gardens and closed gateways (despite that there, tracking happens too, but it is out of reach of the users to even realize/decide).

Explanation: Evercookie, fingerprinting, cookies, retargeting, detection of user agents though hardware architecture etc. is NOT what users want. As at least one big vendor is big into ads, this policy will be hard to push through, yet the most important.

This feature is the most important and only diminished by outdated client side software (see rule 1).

### 3. New/added technology should not add new - more or less implementation independent - attack vectors.

Bad examples: This for instance has been ignored when introducing canvas, webgl and possibly webasm regarding fingerprinting

Thus if shadow dom introduces such vectors, then it is a problem. I cannot judge if streaming shadow doms would do that, but in case it would, that's a problem (see rule 2).

### 4. Prevalent outdated server software

Say outdated or badly written software (versions) such as load balancers, proxies, apache/nginx, php, fpm, node, wordpress, sanitizers should be considered but ultimately disregarded if there is no easy upgrade path respecting issues.

Reason: Web standards are not responsible for bad citizins. They are however responsible for making sure the technology itself is no threat to security (see rule 3). This for instance has been ignored when introducing canvas, webgl and possibly webasm.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/913#issuecomment-719944196