I know an adult woman, her dad is 'stalking' her via her cellphone, he's a cop. Constantly texts her how he knows exactly where she is and she is paranoid about it. I explained to her how yes, he can tap into her cellphone unless she pulls out her battery. Advised her to change her cellphone number and take screenshots of all texts he's sent to her. Smartphones are spy devices with antennas, anyone can stalk someones location. Now she knows to get an order of protection against him.
That's a lotta FUD. Is the "Find my iPhone" function turned on? Or the feature where friends share their locations with their contacts? Or do they constantly post their own GPS coordinates on social media?
As for "smartphones are spy devices"... everything is a "spy" device. Your use of a computer right now, sharing this story but without being an "anonymous coward," has already placed your adult woman's life in danger, because now people can connect the dots between you and them...
At any rate, I, too, know some paranoid people. They think the federal government is interested in them! Of all 7.8 BILLION humans currently alive on the planet earth, THEY (the 1 person) is somehow top of the list! It's not logical thinking, it's barely rational, but they're paranoid and believe they're "next."
Essentially, they're reinforcing their own echo-chamber effect to only listen to confirmations of their conceived notion of correctness rather than truly encouraging discourse on the matter. Her poll options are, "yes" and "yes" -- and several Twitter replies have been deleted.
Personally, it seems they are an engineer looking for a problem to solve to help justify their job... and that's just sad in itself.
That is really it. If we techie/hacker types want to live in a society we believe in, now is the time to say 'This is ENOUGH! THIS IS NOT WHAT I SIGNED UP FOR!', leave the country, renounce your citizenship, and band together anew, whether squatting territory that is technically another's, pretending there is still Terra Nulla and colonizing it, or building a seastead and finding the goods and services that will allow you the purchasing power to collectively own what you want.
Why is this necessary? IP Laws, followed by collective bargaining/purchasing power, followed by a direct democracy of your peers (hint: the average citizen in your country is *NOT* one of your peers. Hell, many of us can agree the majority of our family members are not either. If you disagree, consider yourself lucky. You have either have a smart family, or are suitably average yourself!) With those three issues out of the way hardware can be purchased tailored to the market, or sufficient dedicated individuals will be collected to rapidly reverse engineer, exploit, reflash, or redesign a device to meet the needs of the domestic public. Anything short is simply pissing unwind and wondering why you're wet and reek of piss afterwards.
The TVs are no longer "smart" if they simply shovel Google adverts into your face like you're some kind of ad-hungry maggot. (For once I'm glad I have a dumb smart tv... aka, Panasonic.)
There is nothing clever about this. This is just security failing because of the incompetency of the gas station managers. Nothing about this could be called a hack.
You literally just described a security hack. The failing on one behalf allows another behalf to take advantage of by way of adopting an additional tool or device. The scenario is literally a "hack," unless you're referring to yourself as being a "hack" of a security expert.
Java on mobile phones, back when phones were not very smart, was a mess with many different layers of API's to follow. I forget what they called that mobile version of JAVA but each phone vendor had different application stores and different application requirements.
Apple showed that the market for downloading applications on mobile devices was viable again( remember Palm did it years before ) and Google just followed their lead. Had the phone vendors considered their Sun JAVA mobile API's sufficient they could have competed but they were stuck with what Sun provided and it was not really so good for the rich smartphone OS which was becoming the norm.
J2ME (Java 2 Mobile/Micro Edition) was their primary mobile platform, and it was successfully deployed in may places. BlackBerry OS was built upon JME itself (before Java 1.0 got to Java 1.2 aka "Java 2").
Along those lines of Oracle's current claims, the future success of Java as a mobile platform/ecosystem was somehow stunted by Android OS... and not the continued failures and feature deficits of the underlying Java ME platform and their existing commercial mobile OSes. If I recall, the Java ME platform had such a lousy stench to it that Apple quickly dismissed its usage in creating iOS (so it was in the running but tripped on its own insufficiencies).
I agree, LoB, that Oracle's purchase of Sun (and thus Java) was not primarily for mobile ambitions because Sun quick the mobile market before talks began! Sun needed an exit strategy and Oracle came with open arms.
It's used to align things when CSS fails to have a proper solution. It's used for interfaces, games, etc. It can be used to determine what resolution of image to dynamically fetch for your device. No point in downloading a 4K photo for a laptop that's not even full HD.
You should be programming for the RELATIVE CONTENT POSITIONING and allow auxiliary scripts to dynamically fetch the right-sized create assets... Unless you're talking about scroll-over advertisements that are supposed to take over the entire screen, then yeah sure I can see why you're upset.
The year 2001 called, it wants its fixed content positioning CSS definitions back...
Are they implying that unpopular opinions are a new thing and are the Internet's fault? What is this... the basis for censorship?! Humans, please stop blaming the Internet or Mikey's Web Page for reinforcing you own strongly-held beliefs!!
It's meant to be their "Slack" or "Teams" (formerly Yammer) competitor within the enterprise G Suite platform. I don't believe Google has any other service that accomplishes this role.
Did you see any reactions from folks who are behind ad-blockers software?
Well, there's certainly a difference between the concept of the new API and whether there are bugs within its implementation. I'm comfortable with the concept; I sympathize with you (and the other developers) if the API implementation is buggy -- and released with those bugs intact. I hope the developers are providing constructive feedback in the bug reports (there are bug reports I would imagine) in attempts at fixing the API implementation issues.
Oh, I see that (according to you) I don't actually understand what's going on... Surprise, I actually do. Another surprise, I've been doing this sorta stuff (platform APIs) for several decades, so from my experience I'm looking at this puzzle entirely differently.
First, the new API is not a replacement. It is truly a new API meant to be leveraged by extension developers to make more-powerful extensions. (But that scenario is not as sensational... it's more dramatic to exclaim that they're looking to wholeheartedly replace webRequest API with declarativeNetRequest API...)
Second, the specs themselves talk about "block" and "redirect" actions.
Third, reg-ex (regular expression) pattern definitions/matching does allow known GA (for example) tags/scripts/calls to get whitelisted (regardless of their context).
Fourth, this API is not exclusive (an either/or scenario) to an extension leveraging other API. Back to my First point, the new API allows extension developers to be more creative and increase overall performance of how they conduct their content filtering rules.
Fifth, although you think I'm a total idiot who should step away from the keyboard -- which is ironic cuz I think the same of you, oh dear "Anonymous Coward" -- not every new API is a direct assault against ad-blocking. It's a *NEW* API allowing you to do *NEW* things in *NEW* ways. It is NOT a replacement of the old method, but simply a new API.
Content filtering tools (whether they block ads, strip HTTP headers, steal your traffic behavior, or replace JPEGs with GIFs) are always going to be around (and you know that Chromium is open-source so you can always fork the code and jerry-rig these changes) so my only take-away from this whole brouhaha is that some developers are not happy because of how other developers behave. Maybe the Chromium developers are being evil... or maybe they're looking for more constructive feedback based on actual attempts by extension developers of adopting the API instead of simply hearing how passionately some people argue for the sake of arguing and cannot see the forest from the trees.
You are wrong on a few points. 1) onBeforeRequest can cancel a request before it is actually made (hence the "Before" part of the name), and the server would see nothing. Even then, blocking network requests still leaves holes all over the page (e.g. iframes, divs) that the cosmetic filters clean up. 2) the new API doesn't support selective whitelisting, therefore all requests to googleanalytics.com and others would be allowed to prevent page breaking, as per-site rules are not allowed. 3) the type of filters is limited to hostname and limited path matching, rather than a whole suite of conditions allowed today. 4) there is a limit of 30,000 rules, which isn't enough to load EasyList, let alone a combination of filter sources.
You say "selective whitelisting" and then proceed to explain how path matching works.
You say per-site rules... but isn't that the job of the ad-blocking extension to understand the context of the browser requests?!
If the filters are defined in a very static and crappy manner, then the definitions should get rewritten/optimized. The filters should not require explicit DNS entry matches but rather allow for wait for it... path matching.
As for being "wrong on a few points"... none of the points you've shared demonstrate an incorrect understanding of the declarativeNetRequest API on my behalf. They're merely specific technical details which the API docs themselves do not discuss... because it's an API, not an ad-blocking extension.
In Manifest V3, this API will be discouraged (and likely limited) in its blocking form. The non-blocking implementation of the webRequest API, which allows extensions to observe network requests, but not modify, redirect, or block them (and thus doesn't prevent Chrome from continuing to process the request) will not be discouraged. As an alternative, we plan to provide a declarativeNetRequest API (see below). The details of what limitations we may put in the webRequest API are to be determined.
Thank you for digging this up! So it's "not be discouraged." They're hoping to trade an increase in network performance (i.e. reduction in resource calls) by decreasing the request filtering "power" [and transitioning request filtering to the pre-request "onBeforeRequest" stage].
Those who use the older API won't ever be happy to change their code/model, but those who leverage the new API may actually experience a reduction in dropped network traffic and an associated increase in browser user experience. Interesting trade-off...
I believe gathering detailed performance metrics of any revamped ad-blocking extensions would truly convince devs whether the Chromium implementation of the API really does improve overall performance... or whether it's just a dick move by some Chromium devs as part of an evil plan. (Cue the conspiracy theorists...)
I fully respect the disdain for all things Alphabet Soup (formerly known as Google Inc) but the specs to chrome.declarativeNetRequest appear to suggest a different extension programming model to accomplish the same thing.
Instead of loading a separate web document (as webRequest API does) the new API allows an extension to run through its rules at the onBeforeRequest stage -- in other words, instead of intercepting a separate network request mid-stream the API provides the means to evaluate the network request BEFORE going all the way through.
Another way to look at it is like a (network routing) proxy service. The proxy runs through client-side rules first (whereby the rules.json may have "block" and "allow" and "redirect" action types) and reacts accordingly all BEFORE dropping mid-stream packets.
As I ponder this a bit more, it seems that an ad-blocking extension that utilizes the new declarativeNetRequest API would actually DECREASE the amount of hits an ad-server would experience since the browser would never initiate a connection to the ad-server. To this end, the specs say that iframes and images blocked by the declarativeNetRequest API would collapse at the DOM (thus killing the html content within the iframe from ever being loaded).
Question: Did I understand the SPECS correctly? (Yes, I am ignoring the brouhaha otherwise as well as the claim that [oh no] ad blockers have a new API at their disposal...)
Whomever the IT admins (network, systems, cloud, dev) were that facilitated this, I wonder if their resumes were in there. But mostly, I wonder if they'll update their resumes to reflect the more truthful facts regarding their lapse in proper security practices.
Blanket blocking of feedback is wholesale violation of First Amendment "Free Speech" rights, and a violation of various feedback-required public discourse laws and rules across all government branches. To this day, many municipalities are getting sued for NOT providing transparency and NOT actively soliciting public feedback... especially as it relates to local matters such as sexual predators moving across school grounds, design reviews for sun-blocking skyscrapers, construction practices in residential neighborhoods, and changes in electoral jurisdictions (which was itself overturned by SCOTUS).
Slashdot Mirror
I know an adult woman, her dad is 'stalking' her via her cellphone, he's a cop. Constantly texts her how he knows exactly where she is and she is paranoid about it. I explained to her how yes, he can tap into her cellphone unless she pulls out her battery. Advised her to change her cellphone number and take screenshots of all texts he's sent to her. Smartphones are spy devices with antennas, anyone can stalk someones location. Now she knows to get an order of protection against him.
That's a lotta FUD. Is the "Find my iPhone" function turned on? Or the feature where friends share their locations with their contacts? Or do they constantly post their own GPS coordinates on social media?
As for "smartphones are spy devices"... everything is a "spy" device. Your use of a computer right now, sharing this story but without being an "anonymous coward," has already placed your adult woman's life in danger, because now people can connect the dots between you and them...
At any rate, I, too, know some paranoid people. They think the federal government is interested in them! Of all 7.8 BILLION humans currently alive on the planet earth, THEY (the 1 person) is somehow top of the list! It's not logical thinking, it's barely rational, but they're paranoid and believe they're "next."
They're already working on the AMP for Email standard -- where email self-modify their contents on-the-fly.
The Google Chrome engineer who posted this ask to the W3C mailing list ( https://lists.w3.org/Archives/... ) also made a social media poll, https://twitter.com/estark37/s...
Essentially, they're reinforcing their own echo-chamber effect to only listen to confirmations of their conceived notion of correctness rather than truly encouraging discourse on the matter. Her poll options are, "yes" and "yes" -- and several Twitter replies have been deleted.
Personally, it seems they are an engineer looking for a problem to solve to help justify their job... and that's just sad in itself.
That is really it. If we techie/hacker types want to live in a society we believe in, now is the time to say 'This is ENOUGH! THIS IS NOT WHAT I SIGNED UP FOR!', leave the country, renounce your citizenship, and band together anew, whether squatting territory that is technically another's, pretending there is still Terra Nulla and colonizing it, or building a seastead and finding the goods and services that will allow you the purchasing power to collectively own what you want.
Why is this necessary? IP Laws, followed by collective bargaining/purchasing power, followed by a direct democracy of your peers (hint: the average citizen in your country is *NOT* one of your peers. Hell, many of us can agree the majority of our family members are not either. If you disagree, consider yourself lucky. You have either have a smart family, or are suitably average yourself!) With those three issues out of the way hardware can be purchased tailored to the market, or sufficient dedicated individuals will be collected to rapidly reverse engineer, exploit, reflash, or redesign a device to meet the needs of the domestic public. Anything short is simply pissing unwind and wondering why you're wet and reek of piss afterwards.
WUT?!
The TVs are no longer "smart" if they simply shovel Google adverts into your face like you're some kind of ad-hungry maggot. (For once I'm glad I have a dumb smart tv... aka, Panasonic.)
There is nothing clever about this. This is just security failing because of the incompetency of the gas station managers. Nothing about this could be called a hack.
You literally just described a security hack. The failing on one behalf allows another behalf to take advantage of by way of adopting an additional tool or device. The scenario is literally a "hack," unless you're referring to yourself as being a "hack" of a security expert.
There's the saying, "Bite the hand that feeds it!" (Also the slogan used by The Register, but their "it" is I.T.)
I forget what they called that mobile version of JAVA
I believe it was, oddly enough, Java ME (Mobile Edition)
It was Micro Edition (embedded) before it picked up the temporary marketing rebrand of Mobile Edition.
Java on mobile phones, back when phones were not very smart, was a mess with many different layers of API's to follow. I forget what they called that mobile version of JAVA but each phone vendor had different application stores and different application requirements. Apple showed that the market for downloading applications on mobile devices was viable again( remember Palm did it years before ) and Google just followed their lead. Had the phone vendors considered their Sun JAVA mobile API's sufficient they could have competed but they were stuck with what Sun provided and it was not really so good for the rich smartphone OS which was becoming the norm.
J2ME (Java 2 Mobile/Micro Edition) was their primary mobile platform, and it was successfully deployed in may places. BlackBerry OS was built upon JME itself (before Java 1.0 got to Java 1.2 aka "Java 2").
Along those lines of Oracle's current claims, the future success of Java as a mobile platform/ecosystem was somehow stunted by Android OS... and not the continued failures and feature deficits of the underlying Java ME platform and their existing commercial mobile OSes. If I recall, the Java ME platform had such a lousy stench to it that Apple quickly dismissed its usage in creating iOS (so it was in the running but tripped on its own insufficiencies).
I agree, LoB, that Oracle's purchase of Sun (and thus Java) was not primarily for mobile ambitions because Sun quick the mobile market before talks began! Sun needed an exit strategy and Oracle came with open arms.
He invented the Internet. (Not to be confused with the OTHER guy who invented the Internet.)
It's used to align things when CSS fails to have a proper solution. It's used for interfaces, games, etc. It can be used to determine what resolution of image to dynamically fetch for your device. No point in downloading a 4K photo for a laptop that's not even full HD.
You should be programming for the RELATIVE CONTENT POSITIONING and allow auxiliary scripts to dynamically fetch the right-sized create assets... Unless you're talking about scroll-over advertisements that are supposed to take over the entire screen, then yeah sure I can see why you're upset.
The year 2001 called, it wants its fixed content positioning CSS definitions back...
Are they implying that unpopular opinions are a new thing and are the Internet's fault? What is this... the basis for censorship?! Humans, please stop blaming the Internet or Mikey's Web Page for reinforcing you own strongly-held beliefs!!
Cyrillic is not a language, it is an alphabet.
True, but the password field doesn't know the difference.
Maybe try an entirely different language, like Arabic or Cyrillic or Hebrew. The same idea applies, though.
It's meant to be their "Slack" or "Teams" (formerly Yammer) competitor within the enterprise G Suite platform. I don't believe Google has any other service that accomplishes this role.
No, it's Bolstering The Stock Market Day
Did you see any reactions from folks who are behind ad-blockers software?
Well, there's certainly a difference between the concept of the new API and whether there are bugs within its implementation. I'm comfortable with the concept; I sympathize with you (and the other developers) if the API implementation is buggy -- and released with those bugs intact. I hope the developers are providing constructive feedback in the bug reports (there are bug reports I would imagine) in attempts at fixing the API implementation issues.
>Fifth, although you think I'm a total idiot who should step away from the keyboard
You are presuming too much and losing your nerve.
Simple question: does regexping mechanism described allow good old blocking by domain or not?
I did reply before drinking my coffee or eating breakfast...
As for blocking by domain? The way I read the specs, yes. The URI is processed as a good ol' string, so RegExing would indeed work.
Oh, I see that (according to you) I don't actually understand what's going on... Surprise, I actually do. Another surprise, I've been doing this sorta stuff (platform APIs) for several decades, so from my experience I'm looking at this puzzle entirely differently.
First, the new API is not a replacement. It is truly a new API meant to be leveraged by extension developers to make more-powerful extensions. (But that scenario is not as sensational... it's more dramatic to exclaim that they're looking to wholeheartedly replace webRequest API with declarativeNetRequest API...)
Second, the specs themselves talk about "block" and "redirect" actions.
Third, reg-ex (regular expression) pattern definitions/matching does allow known GA (for example) tags/scripts/calls to get whitelisted (regardless of their context).
Fourth, this API is not exclusive (an either/or scenario) to an extension leveraging other API. Back to my First point, the new API allows extension developers to be more creative and increase overall performance of how they conduct their content filtering rules.
Fifth, although you think I'm a total idiot who should step away from the keyboard -- which is ironic cuz I think the same of you, oh dear "Anonymous Coward" -- not every new API is a direct assault against ad-blocking. It's a *NEW* API allowing you to do *NEW* things in *NEW* ways. It is NOT a replacement of the old method, but simply a new API.
Content filtering tools (whether they block ads, strip HTTP headers, steal your traffic behavior, or replace JPEGs with GIFs) are always going to be around (and you know that Chromium is open-source so you can always fork the code and jerry-rig these changes) so my only take-away from this whole brouhaha is that some developers are not happy because of how other developers behave. Maybe the Chromium developers are being evil... or maybe they're looking for more constructive feedback based on actual attempts by extension developers of adopting the API instead of simply hearing how passionately some people argue for the sake of arguing and cannot see the forest from the trees.
You are wrong on a few points. 1) onBeforeRequest can cancel a request before it is actually made (hence the "Before" part of the name), and the server would see nothing. Even then, blocking network requests still leaves holes all over the page (e.g. iframes, divs) that the cosmetic filters clean up. 2) the new API doesn't support selective whitelisting, therefore all requests to googleanalytics.com and others would be allowed to prevent page breaking, as per-site rules are not allowed. 3) the type of filters is limited to hostname and limited path matching, rather than a whole suite of conditions allowed today. 4) there is a limit of 30,000 rules, which isn't enough to load EasyList, let alone a combination of filter sources.
You say "selective whitelisting" and then proceed to explain how path matching works.
You say per-site rules... but isn't that the job of the ad-blocking extension to understand the context of the browser requests?!
If the filters are defined in a very static and crappy manner, then the definitions should get rewritten/optimized. The filters should not require explicit DNS entry matches but rather allow for wait for it... path matching.
As for being "wrong on a few points"... none of the points you've shared demonstrate an incorrect understanding of the declarativeNetRequest API on my behalf. They're merely specific technical details which the API docs themselves do not discuss... because it's an API, not an ad-blocking extension.
Never mind, I found it. It's not in API documentation, but in a Google docs proposal for Manifest V3:
Thank you for digging this up! So it's "not be discouraged." They're hoping to trade an increase in network performance (i.e. reduction in resource calls) by decreasing the request filtering "power" [and transitioning request filtering to the pre-request "onBeforeRequest" stage].
Those who use the older API won't ever be happy to change their code/model, but those who leverage the new API may actually experience a reduction in dropped network traffic and an associated increase in browser user experience. Interesting trade-off...
I believe gathering detailed performance metrics of any revamped ad-blocking extensions would truly convince devs whether the Chromium implementation of the API really does improve overall performance... or whether it's just a dick move by some Chromium devs as part of an evil plan. (Cue the conspiracy theorists...)
I fully respect the disdain for all things Alphabet Soup (formerly known as Google Inc) but the specs to chrome.declarativeNetRequest appear to suggest a different extension programming model to accomplish the same thing.
Instead of loading a separate web document (as webRequest API does) the new API allows an extension to run through its rules at the onBeforeRequest stage -- in other words, instead of intercepting a separate network request mid-stream the API provides the means to evaluate the network request BEFORE going all the way through.
Another way to look at it is like a (network routing) proxy service. The proxy runs through client-side rules first (whereby the rules.json may have "block" and "allow" and "redirect" action types) and reacts accordingly all BEFORE dropping mid-stream packets.
As I ponder this a bit more, it seems that an ad-blocking extension that utilizes the new declarativeNetRequest API would actually DECREASE the amount of hits an ad-server would experience since the browser would never initiate a connection to the ad-server. To this end, the specs say that iframes and images blocked by the declarativeNetRequest API would collapse at the DOM (thus killing the html content within the iframe from ever being loaded).
Question: Did I understand the SPECS correctly? (Yes, I am ignoring the brouhaha otherwise as well as the claim that [oh no] ad blockers have a new API at their disposal...)
+1. Thank you for the tip!
Whomever the IT admins (network, systems, cloud, dev) were that facilitated this, I wonder if their resumes were in there. But mostly, I wonder if they'll update their resumes to reflect the more truthful facts regarding their lapse in proper security practices.
Blanket blocking of feedback is wholesale violation of First Amendment "Free Speech" rights, and a violation of various feedback-required public discourse laws and rules across all government branches. To this day, many municipalities are getting sued for NOT providing transparency and NOT actively soliciting public feedback... especially as it relates to local matters such as sexual predators moving across school grounds, design reviews for sun-blocking skyscrapers, construction practices in residential neighborhoods, and changes in electoral jurisdictions (which was itself overturned by SCOTUS).