Though companies who want to see your data might not be so keen.
On my phone, but will try it out when I get home.
15 years from now, will this site still be up?
Will you be able to open your projects from today, then?
I think web only is a really compelling way to get someone to try a product, but I’d much rather install a tool like this. Unless you could host the site yourself, of course.
- if the tool is updated continuously for 15 years it’ll still be up
- if it’s not updated, it will be technically irrelevant anyway and you’ll have switched to another tool by then
Future support is overrated for tools, just use one now and worry about tomorrow later.
Other points that weren't raised - I want to be free to work in situations where I have poor or no internet e.g. when traveling.
Tying tools down to whether or not a website is available and you have reliable internet access is a huge step backwards in my opinion.
I also use older software quite often that has long since been updated, such as older versions of Audacity, Ableton, Adobe Premiere, etc. for various reasons such as: not wanting to spend money, avoiding spyware, ads (see: Windows 11), and other bloat which often IMO negatively outweighs the positivity of new features. There are a lot of other small utilities that I still use that are 10+ years old because they still work fine and I know how to use them blind-folded. There are also tools that haven't received updates in many years but still work great, why would I bother to look for something new that potentially will spy on me and not offer the same functionality?
But sometimes you have important old projects.
For example, my parents used photoshop elements to touch up all of my sister’s baby photos.
But my parents were not very technical and kept most of the photos as photoshop project files.
Idk if project files that old will open in newer versions of photoshop, but I don’t need to worry, bc I can always find a download of that old photoshop elements and open the projects in there.
It’s not as much about daily use as it is about planned (or inevitable) obsolescence.
Everything web based WILL become unusable or change drastically some day.
One day, potentially out of nowhere, web based tools can just vanish.
Imagine you were working on a film school senior project and poof your video editing tool was just gone!
Even if they gave a week’s notice, that wouldn’t be enough.
That can’t happen with something like Sony Vegas.
I believe blender can do this, for example.
Nothing web specific about it.
Except I have to have those servers to run it on. It's the basic premise of why cloud vs onPrem. I didn't think that really needed to be stipulated at this level on this particular forum.
That software then does not require servers to run on, since it supports local processing.
In this way it remains accessible in the future and scalable right now. (Assuming local processing would be slow enough to hurt the experience)
Honestly, I didn’t think this concept needed to be explained at this level either.
- I pledge to only make network connections to X, Y and Z
- I pledge to only make GET requests to http://example.com/foo/*
- I pledge not to use canvas, iFrames or storage APIs
This info wouldn't be immediately useful to most users, but it could massively help experienced users with trusting local utilities.
Doesn't solve any trust issue since data can be send as part of the URL, and the backend response can change at will.
* first requirement can already be done using Content-Security-Policy header
* haven't found a suitable header for the second requirement
* third requirement can be done with Permissions-Policy header
Not relying on a server makes this functionality available for downloaded sites. I'm a big fan of offering single file builds for web utilities, and the pledge should be part of that build instead of something the user supplies.
Having this as a runtime API would enable easier integration - say I'm developing a video editor that needs some WASM blobs. It might be a lot easier to load the blobs and pledge no further network access than having the URLs known on the server-side.
A bit fiddly for sure - but seems comprehensive enough.
It does.
> You can, in fact, use the network tab to monitor a page's ongoing network activity as originally suggested.
Did you forget that this comment chain was about leaking data to the server? Observing that you have leaked (note: past tense!) your data is not a recommended way to prevent leaking data.
I am sitting here looking at a new entry added from a button click that creates a network call. Either you are wrong or confused about what the discussion is about.
Reading a historic log that shows you have been pwned does not prevent you from being pwned. It's the wrong tool for the job.
If you had done this, even spending 10 hours looking at network traffic, you wouldn't have been protected from this hack: https://www.theverge.com/2018/4/24/17275982/myetherwallet-ha...
That was a technically sophisticated hack, but there are simpler ones, like social engineering someone to take over their site.
Put putting hacks aside...
Say you have a site and it doesn't mention whether the data is sent to a server and you want to find out. Now let's say that site does a backup to server but only when localstorage has run out of space, but you don't know that.
When you test the site in the network tab, and you haven't run out of localstorage space then you will see no XHR and assume it's all good, it never sends to the server.
You then use the app for a few days, hit the localstorage limit and it sends stuff to the server without you knowing. And yeah you can keep the network tab open all the time if you have the discipline, but you only know once your data has been sent. It is too late.
If you care enough about whether it sends stuff to the server to look at a network tab, then you probably care enough to want to know for sure.
With the web as it is now there is only one way - trust the site and hope they do the right thing, and are secure. Or only put stuff on there you are happy to leak.
So, made up situation: if you are using this tool to edit and release a whistleblowing related video as a journalist. Maybe you shouldn't!
You probably instead want a local app, running on linux, on a machine that is disconnected from the network.
Future behaviour may be different.
Also on the web code can change. Either the site owner or by a hacker. There is value in checking network requests if you need to but it isn't fool proof.
Break the cycle.
That's an interesting question, but I think it's also equally difficult to prove for non-browser software.
With web applications doing the same is more difficult, because you need to pass some requests, and some requests need to pass while others could be smuggling data.
https://addons.mozilla.org/en-US/firefox/addon/work-offline-...