I notice that you enabled hyperlink auditing. This little feature didn't exist in the Qt documentation when I added it, however, it's magically supported. You should not enable this feature as some newer versions of HTML provide ping capabilities. That is, when you click on a link, it sorts of notifies the target site. I'll add some information to the option.
That's the shortest possible label text I came up with, off the cuff.
Still not ideal; I would hope to mention "privacy" or "privacy issue" as part of the label
Best, I think, would be to place hyperlink(s) to relevant reference(s) beside each pref, rather than struggling to tersely "explain" why each setting exists, as well as the rationale behind its suggested value. For some settings, it seems advisable to provide warning/explanation where a certain setting/value "may break things"... but nowadays all developers seem to avoid all-but-absolutely-necessary text(s) due to the accompanying chore of translation. BTW, devs should refrain from tacking a period to the end of each label, unless it represents a complete sentence.
Thanks for noticing that detail in my screencap & for explaining.
Back in (2009?) when I first read about that coming down the pike, I was aghast.
"What are they thinking?!? Devilspawn!"
Rather than adding a proxomitron rule to strip any occurrences found, I decided to generate an alert... and seldom (never? aside from testing) actually encountered that href attribute in the wild. Now, years later... from habit of browsing with ff + RequestPolicy addon, proxo is typically bypassed, so (Pop! goes my false sense of security) your suggestion is especially welcome.
Ratbastards added support for this "feature" into webkit without it being part of the official spec (mozilla has send_beacon, and discussion of default ping behavior and whether or not to even offer a pref to disabled it, is still underway)... and the followup will be "business, as usual" ~~ "Eveebodee's doing it already, all the big browsers, so it should be added as an official part of the spec."
Can we trust that webkit v.X.xx won't sidestep this pref?
I worry that because we don't own/ship enough of the stack, we can't ensure that doesn't happen. WebCore/loader/PingLoader.cpp ...and the horse you rode in on!
some newer versions of HTML provide ping capabilities
.
proxying/pre-parsing each document to change DOCTYPE declaration to "...4.1 Transitional" (not that you've suggested such) would be a ham-fisted approach and would certainly "break some sites' pages"... but I'm convinced that the ability to perform rule-based pre-parsing is essential in assuring that our "user-agent" represents (and defends) OUR interests.
I don't know whether HTTPSwitchboard covers (handles) all the various possibilities.
Sadly, I had only considered #4 (below) in my proxomitron filter.
Playing catch-up today, I've read that each of the following has been observed in the wild:
"Ping-To:" HTTP response header
"Ping-From:" HTTP request header
header containing "Content-Type:text/ping"
{a ping="URL,orCommaSeparated,MultipleURLs" ...} (attribute specified for hyperlink ("a" or "area") elements)
{a ping="URL, or space separated MultipleURLs" ...}
{a rel="ping" ...}
I'm posting to OpenDiscussion because I don't yet have a well-formed suggestion or request, just an open-ended question:
Is it feasible (as in code-able, not "usable, by the AverageJoe") to craft an inbuilt framework, with functionality like proxomitron and/or HTTPSwitchboard, within a webkit-powered browser?
Last edit: sandax 2014-08-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There are times when I feel that a fragmented sentence is more appealing than a fragment.
My rationale is not important. Choices are important. The process of providing them, however, becomes tedious and expensive. Users do not submit enough information about such delicate matters as thoughts. Instead, they wish to see ideas that bring them comfort without sacrificing effort and time. The concept is old and repetitive. You ought to place your verbosity inside a user’s document. Are you willing to compose such a thing?
WebKit is being removed in a future version of Qt.
Yes, it is possible. Is it consuming? Very. The current painters of Web data are masterfully clever. Revenue owns them. HTML designs are driven by revenue. The critical parties are not interested in your privacy and in your electronic rights. And so, you have designers designing products that hopefully limit the inspection of your data. Dooble is a small inconsequential vessel.
See Source/dwebpage.cc. Dooble modifies some content already, namely HTTP to HTTPS without requiring additional software.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
.
[] permit embedded hyperlink auditing (ping) requests (suggested setting: NO/unticked)
That's the shortest possible label text I came up with, off the cuff.
Still not ideal; I would hope to mention "privacy" or "privacy issue" as part of the label
Best, I think, would be to place hyperlink(s) to relevant reference(s) beside each pref, rather than struggling to tersely "explain" why each setting exists, as well as the rationale behind its suggested value. For some settings, it seems advisable to provide warning/explanation where a certain setting/value "may break things"... but nowadays all developers seem to avoid all-but-absolutely-necessary text(s) due to the accompanying chore of translation. BTW, devs should refrain from tacking a period to the end of each label, unless it represents a complete sentence.
Thanks for noticing that detail in my screencap & for explaining.
Back in (2009?) when I first read about that coming down the pike, I was aghast.
"What are they thinking?!? Devilspawn!"
Rather than adding a proxomitron rule to strip any occurrences found, I decided to generate an alert... and seldom (never? aside from testing) actually encountered that href attribute in the wild. Now, years later... from habit of browsing with ff + RequestPolicy addon, proxo is typically bypassed, so (Pop! goes my false sense of security) your suggestion is especially welcome.
Ratbastards added support for this "feature" into webkit without it being part of the official spec (mozilla has send_beacon, and discussion of default ping behavior and whether or not to even offer a pref to disabled it, is still underway)... and the followup will be "business, as usual" ~~ "Eveebodee's doing it already, all the big browsers, so it should be added as an official part of the spec."
ref, for above:
https://www.mail-archive.com/dev-platform@lists.mozilla.org/msg08435.html
http://codeverge.com/mozilla.dev.platform/intent-to-ship-navigator.sendbeacon/1983861
Can we trust that webkit v.X.xx won't sidestep this pref?
I worry that because we don't own/ship enough of the stack, we can't ensure that doesn't happen.
WebCore/loader/PingLoader.cpp ...and the horse you rode in on!
.
proxying/pre-parsing each document to change DOCTYPE declaration to "...4.1 Transitional" (not that you've suggested such) would be a ham-fisted approach and would certainly "break some sites' pages"... but I'm convinced that the ability to perform rule-based pre-parsing is essential in assuring that our "user-agent" represents (and defends) OUR interests.
In-browser proxying seems (to me) is what we need. Native, inbuilt ~~ not bolt-on, like the HTTPSwitchboard addon for Chrome/Chromium (which, among other things, takes a stab a thwarting "ping" traffic).
https://chrome.google.com/webstore/detail/http-switchboard/mghdpehejfekicfjcdbfofhcmnjhgaag
I don't know whether HTTPSwitchboard covers (handles) all the various possibilities.
Sadly, I had only considered #4 (below) in my proxomitron filter.
Playing catch-up today, I've read that each of the following has been observed in the wild:
"Ping-To:" HTTP response header
"Ping-From:" HTTP request header
header containing "Content-Type:text/ping"
{a ping="URL,orCommaSeparated,MultipleURLs" ...} (attribute specified for hyperlink ("a" or "area") elements)
{a ping="URL, or space separated MultipleURLs" ...}
{a rel="ping" ...}
I'm posting to OpenDiscussion because I don't yet have a well-formed suggestion or request, just an open-ended question:
Is it feasible (as in code-able, not "usable, by the AverageJoe") to craft an inbuilt framework, with functionality like proxomitron and/or HTTPSwitchboard, within a webkit-powered browser?
Last edit: sandax 2014-08-08
There are times when I feel that a fragmented sentence is more appealing than a fragment.
My rationale is not important. Choices are important. The process of providing them, however, becomes tedious and expensive. Users do not submit enough information about such delicate matters as thoughts. Instead, they wish to see ideas that bring them comfort without sacrificing effort and time. The concept is old and repetitive. You ought to place your verbosity inside a user’s document. Are you willing to compose such a thing?
WebKit is being removed in a future version of Qt.
Yes, it is possible. Is it consuming? Very. The current painters of Web data are masterfully clever. Revenue owns them. HTML designs are driven by revenue. The critical parties are not interested in your privacy and in your electronic rights. And so, you have designers designing products that hopefully limit the inspection of your data. Dooble is a small inconsequential vessel.
See Source/dwebpage.cc. Dooble modifies some content already, namely HTTP to HTTPS without requiring additional software.
Indeed! See the new 1.56 version.