I want web can run any code if i agree. be cause the hardware is i paid. it is mine.

[WebWeWantBot]

---

title: I want web can run any code if i agree. be cause the hardware is i paid. it is mine. date: 2021-02-27T04:33:03.960Z submitter: Leo Lee number: 6039cb7f69b8885e3eac7057 tags: [ ] discussion: https://github.com/WebWeWant/webwewant.fyi/discussions/ status: [ discussing || in-progress || complete ] related:

• title: url: type: [ article || explainer || draft || spec || note || discussion ]

web app can fast dev. i want to run any code on my cellphone. android ori app dev is too hard. and i do not want to use market let any one download my app. my app just for my team. so i want the web app can do anything. if not agree just not run . there is not safe problem. do not think app is for all people. we buy cellphone dev app just to run my code. and do not need others run the code.

---

If posted, this will appear at https://webwewant.fyi/wants/6039cb7f69b8885e3eac7057/

[aarongustafson]

It seems like this is about running untrusted/non-permitted code, which is incredibly risky. I believe that localhost does not have the same guardrails as the web in terms of this stuff. Would things like Enterprise Policy also trump browser behavior/user engagement for permissions and code execution?

@HarneetSidhana could you weigh in here?

[bradisbell]

I won't speak for Leo, but I have many of the same general frustrations. I am regularly blocked by overbearing specifications and implementations that sacrifice functionality in all use cases for a sense of protection in some. Here are some off-the-cuff examples:

• Battery Status API -- It was very useful for relaying battery state to remote users over a WebRTC call in live news situations, so that the remote end could plan if they were about to lose video, coordinate bringing fresh batteries, etc. The feature was eliminated out of a fear of fingerprinting. Why would I be worried about fingerprinting of my own code that I wrote? I have no choice to trust or not trust my code. Neither do my users. This was decided for everyone.
• Web MIDI API -- Some implementers will not fully enable this API, blocking SysEx and potentially other things. If the user decides they can trust something, they should be allowed to do that. User agents work for the users, not in place of them. They should empower the user to have the functionality they want, and not prevent them from doing basic things like programming their synthesizer, out of some broad security policy.
• Audio Autoplay -- There is no way to request that the user allow autoplay of audio. There should be. There are several legitimate use cases where audio should be allowed without user interaction. Instead, the relevant specifications make assumptions following the most common use cases, damaging the usability of these browser features for other use cases in the process.
• Filesystem -- The new filesystem APIs are great to see, but have a lot of security concerns baked into them which makes these new APIs not useful for many use cases. (Specific comments are left on that repo's issue board.)
• Web Workers -- If the user wants more space in a cache, why not give it to them? Maybe someone wants to store a terabyte cache for some reason. Why should the user agent deny this?
• Memory Limits -- If there is no technical reason to limit memory, why not allow a page to consume a ton of it if the user chooses?
• CPU Limits -- CPU and timer throttling is done, regardless of whether the user wants it or not. Perhaps the user wants to actually use their CPU on what they're doing on this web page.

All of this boils down to a debate to be had. Who is responsible for safety and security? I think everything should have safe and secure defaults, but it should be easy for the user to choose more functionality if they want it. I also think that users should be able to add origins they deem as safe.

Today, it's seemingly more often the case that the implementers believe they understand all the use cases better than the user does. This is having serious implications for innovation, business, and ultimately the users who are left with poor user experiences or the inability to do certain tasks.

Finally, and probably more in-line with Leo's post, I think users should be able to configure their own origins they consider safe. Not everyone uses localhost... many of us use specific hostnames, and it isn't always possible/practical to get a trusted certificate, or install a custom root certificate. If I run the network and want to put in myapp.test into DNS, and if I configure the browser to trust this, why shouldn't it? Casual users won't go through all of these steps. .test is specifically set aside for use cases like this. And yet, it was deemed in the past that the .test TLD couldn't be unrestricted like localhost is. Chrome used to have a button allowing the user to trust the certificate. Bringing that back would resolve a lot of this without significantly sacrificing security.

If the user explicitly chooses to perform some action, implementations should let them. The specifications should allow this.