add corresponding preference names

[atomGit]

interesting extension - if the developers are not aware, you might also want to look at http-useragent-cleaner which offers some similar functionality - it's legacy and the UI is bad, but maybe there is something to be gained from it's code regarding development of API Manager

i don't know how useful this would be most people, but i think it would certainly be useful to anyone using a custom configuration (ghacks user.js) to display the browser preference name(s) that correspond to the items in the blocked standards list (where applicable) so that these prefs could be reset if the user would rather control this functionality dynamically with API Manager on a per-domain basis

i think it might also be good to link the browser preference name to (in the case of FF for instance) the Moz KB page (kb.mozillazine.org) since it offers a more usable and general description verses many of the current "info" links

fooling with yet another extension in addition to a user.js, uBO, uM, etc., is less than desirable, but if it can eventually make some of this other privacy/security stuff obsolete, then i think it would be attractive to more people

thanks guys

[ghost]

I concur that the current info is too complex. Legacy extensions Privacy Settings and Policy Control is managing it in a neat and more comprehensive way.

[Thorin-Oakenpants]

kb.mozillazine.org

Not https. Also old and often out of date information. kb.mozillazine.org is also more about zilla prefs, not about the actual APIs. A better idea is mouse-over the info icon for a simple popup description.

Also, I made a suggestion elsewhere about breaking down the list into levels - something like

• [ ] Level1 (minimal impact)
  • [ ] Battery pref icon: dom.battery.enabled, info icon: blah blah info hyperlink: https://www.w3.org/TR/battery-status/
  • [ ] Beacon
  • [ ] DeviceOrientation Event Specification
  • [ ] Sensors
• [ ] Level2 (slight breakage / annoyance)
  • [ ] Fullscreen API
• [ ] Level5 (common breakage)
  • [ ] Encrypted Media Extensions
• [ ] Level 10 (prepare to die)
  • [ ] DOM
  • [ ] HTML

Where ticking the level ticks subitems. The list is so long (74 items), that if it can be reduced to say 6 levels, then end-users would be more likely to test with level 1, and a week later level 2, etc. If the levels were collapsible, it might also make for visually easier and less daunting

PS: Battery status is obsolete for web-content. It is now limited to chrome and privileged content since FF52 - see https://bugzilla.mozilla.org/show_bug.cgi?id=1313580

[pes10k]

About 74 standards being too many, I disagree, I think actually its too few! I made these categorizations ~2 years ago, and there are many new ones I need to add (WebVR, Web Speech API, etc.). So, the list will need to get longer before it gets shorter!

BTW, if anyone is interested in contributing, documenting these new standards would be a great place to help!

I'm very open to the idea of presenting the standard listing in a better way, but I don't quite dig the "Level" idea @Thorin-Oakenpants mentions. For one, I dont have the data to say what the break rate for new standards are, or what starts breaking once people log into websites (these numbers are all people interacting with sites w/o logging in). And two, I think its confusing to say "minimal / high / etc. impact" when you're describing a configuration for a specific domain, and not in general.

I'm hoping the EasyList style subscriptions will help this all be more manageable (so fewer people have to interact with these things less often). But I'm def not a UX person, so any further thoughts, suggestions, discussions are hugely appreciated.

I agree that i'd be nice to have a better place to link to than the API specs, but im not aware of any other source thats comprehensive (like @Thorin-Oakenpants said, kb.mozillazine.org is related but not trying to provide the same information. MDN has good info for some standards, but generally has information at the method / data structure level, and not at the standard level.

[Thorin-Oakenpants]

About 74 standards being too many

The number of standards can be whatever it **needs to be***, I said it was "soooo long" meaning for the end-user it can be a bit overwhelming at first glance. Definitely breaking the standards into groups is the only way to go. How you group it is the Q - but it definitely needs compartmentalization

The ghacks user.js for example has some 25 or so sections to cover over 600 preferences. Even if you created 20 categories to over all types of APIs, then it would at least then be manageable/navigable and provide a ceiling but allow growth.

You could, down the track, add visual indicators of breakage as we get info. Something like Light Sensor is zero breakage (green dot), but DOM is massive breakage (red dot). This would be a better way to indicate this info to end users.

Just throwing ideas out there

[jawz101]

I've been working on grouping these up according to my interpretation of how they group. I may add a wiki page. I'll add a column for corresponding about:config entries and some sort of coloring if github allows for that. If it sounds silly someone can delete it :P Several I scratch my head on how to group them but others are fairly group-able.

Personally, I don't like the level 1, level 2 thing. Feels too much like matter of opinion but we could do with a color coding. I'd rather group it by area of interest. You'll see what I mean soon.

[Thorin-Oakenpants]

anything is a start - here's a little something: https://browserleaks.com/features to give you ideas: network, storage, css .. actually that's about all I got from that :lulz:

[jawz101]

okie dokie. I did as much as I wanted for now https://github.com/snyderp/web-api-manager/wiki/API-Notes

It should be easy for anyone to fill in the blanks if they find more.

I wish Github's markdown was a little friendlier where I could scrunch things up better. I didn't really look into that, though.

[Thorin-Oakenpants]

< I wish Github's markdown was a little friendlier

Its pretty limited and hard to prettify

[pes10k]

@jawz101 wow, this is great, thank you!

I'm into categorizing the standards by functionality, I'm a little nervous about blocking by "will break risk". Maybe a good strategy would be the following:

1. Categorizing standards into subheadings, as you've suggested with "PHYSICAL ENVIRONMENT" containing "Battery Status", "Gamepad", etc. These could just go into the data/standards/*.json files.
2. Adding an additional "description" field to each data/standards/*.json value, and displaying that in smaller text below each standard's row on the config page. This might include some anecdotal information about break rates.

I'm no good at all at UX stuff, so any further thoughts you have would be great!

[pes10k]

One thing to note is that the extension doesn't do the same thing as the config flags, so I don't want to display those options as being identical.

The config flag will null out the endpoints in the API, which will cause more breaking than might be necessary.

The extension tries to be more clever about it, but returning a self-referencing proxy object, so that code that expects the feature to be place won't throw / crash / explode. Section 3 of this paper does a more through job explaining the idea, and proxyblock.js has the relevant code in it.

The idea is that even when you tear (say) SVG out of the browser, the below won't throw, and so the non-blocked parts of the page's code will still run uninterupted

var canvas = document.createElement("canvas");
var gl = canvas.getContext("webgl");

// This will throw if
// WebGLRenderingContext.prototype.getShaderPrecisionFormat
// doesn't exist, but will become a NOOP with the proxy blocking technique
var format = gl.getShaderPrecisionFormat(gl.VERTEX_SHADER, gl.MEDIUM_FLOAT);
format.comeAlongBort['are you talking to me'].no.mySonIsAlsoNamedBort() 

[jawz101]

I like your idea. If I had an opinion I'd use collapsible menus for each arbitrary grouping (I.e. If you don't like my names for things, whatever makes sense to you) ... kinda like this:

https://jordnkr.github.io/collapsible/

That way it saves screen real estate and it keeps it a single screen.

As for the about:config thing, what you mentioned sounds like a good selling point. Like, I'd put that in your add-on description because a tinkerer who'd be interested in this sort of extension would first say "Well, can't I just disable these things in my prefs?

[pes10k]

@bengansukh just adding you in here, since you mentioned this might be an issue you'd be interested in working on. If it'd be a good idea to discuss further, lets find a time to meet at school to walk through the code further

[bengansukh]

@snyderp sounds good!