Keep the elements hidden
Opened this issue · 8 comments
Remember which elements we hidde in a certain page. I know this extension don't run in background, but it's boring to choose the elements every time.
Will give some thought to this, but I imagine it would probably only be on a per user basis. Any kind of data collection/community driven approach, goes into an area of GDPR and privacy policy territory, that I'm not really keen to navigate.
@rhardih What do you think of keeping this data in the local store for the extension? That way it doesn't get distributed anywhere and should be all restricted to the browser
i cloned this repo and made something to tackle this.. it works on every page but youtube.. i will try some more things out and make a pull request asap
@samuel-crypto Sure, that would be fine. I do think it should be a non-default option though.
There's a few things to consider:
- Do we want chrome.storage.sync or chrome.storage.local. Do we need the kill history to migrate between devices, or are we happy with just a per machine thing.
- If chrome.storage.sync we need to keep in mind the storage limitations: 512 MAX_ITEMS, 8192 QUOTA_BYTES_PER_ITEM and 102400 max QUOTA_BYTES. Only having 512 unique entries will probably not be enough, so some sort of compression+distribution is probably needed.
- If chrome.storage.local do we need some form of import/export feature, so history is not lost when switching to a new machine?
- How much of the full path to the killed item do we need to store, in order to uniquely remove only that item on subsequent visit. E.g. .class-of-element might be too general and result in spurious hits vs. div.with-some-outer-wrapper div.with-some-inner-wrapper el#some-id might be too specific and too easily made obsolete because of change in content.
This was just off the top of my head. There's probably other considerations we need answered as well, but it's a start.
@rhardih
Just some ideas which I have regarding the points (open to criticism):
-
I would imagine there is really no need to distribute kill history across devices as there might be entirely separate versions of the page on different devices anyway (e.g. on phones vs on laptops vs on wide-screen monitors).
-
(see suggestion regarding 1.)
-
My personal opinion would be not to have it there for now, but eventually to integrate it if request enough - but I do not have a strong opinion on this point
-
An interesting idea might be to use a very general identification (e.g. class of element OR some other property [thus even more general than simply class of element]), BUT to remember the approximate location of this element on the page (X, Y for instance), and filter the list of matched elements by those which are very close (closest) to this location.
So essentially remember elements by some general measurement with low false-negatives and high false-positives and filter off false-positives by matching items very close to the original location (or for example picking the item closest to the location). The problem is of course with ads/other elements which like to change location. Alternatively we can think of some rating system which takes in to account the class name, id, and position in the hierarchy (e.g. the XPath) and comes up with good matches 99% of the time
@rhardih One other thing I just realized - since this is probably an optional feature and not the main purpose of the extension you can forget about making it perfect and simply pick one basic identification method (such as by class, tag name and 2 of the parents above, or just by id), and since this extension is not an ad-blocker that would be it.
Edit: Possible example intended uses:
- You could block the little ad section on the top right on YouTube
- You could block the Stackoverflow ads
- Any site which keeps some annoying element in a particular corner
e.t.c.
@rhardih Final option I see - develop a separate extension with such a feature being central to it