snowwolf

It cost me £25 for replacement cushions which they fitted for me in store. https://www.bose.co.uk/en_gb/products/headphones/headphone_a...

Which I had to replace after 2 years of weekday daily use of 3-4 hours a day.

I’m not sure I class that as ridiculously expensive.

And Apply Pay in London is even better as you don't even need to authenticate the payment.

https://www.apple.com/uk/apple-pay/transport/

What happens when the customer contacts you for support and is using the shielded email service. You don't know the "real" email for the account, and the customer can't email you from the "shield" email. So you have limited means of verifying they are who they say they are. So how do you for disclose account information to them if you can't be sure they are the account owner?

They aren’t trackers in that respect. Read up on the companies in question. They basically provide analytics to mobile apps so they can better understand their customers to allow them to improve the experience of the app.

It’s the equivalent of Google Analytics.

Now how those companies then use the data they collect as part of providing analytics is another question (and why lots of people prefer to block Google Analytics for example)

The thing is they aren’t actually selling that data. All the services mentioned are paid services that ring are paying to use. And ironically they sprang up to fill a need because Google and Apple made it almost impossible to do app install attribution to protect people’s privacy. So we now get more invasive tracking to work around that.

I wonder why Ring is being specifically called out for this practice. This combination of “trackers” are very common in the app ecosystem as they perform much the same analytics functions used on the web ecosystem (e.g. Branch offers ad campaign attribution - did this user sign up from an ad campaign and which one so I can work out ad ROI). I’d hazard a guess that analysis of the apps on your phone (Android and iOS) would result in well over 50% of them using some combination of these services.

What’s more interesting is that it could be argued these fall under the intent of the EU cookie directive (even though in a lot of cases they don’t actually use cookies). The only app I have seen asking for cookie like consent is Airbnb (who use all of these same services and more)

Just thought I should point out that Libreelec is Kodi. It’s just a stripped down OS with just enough on it to run Kodi so it can be fast and stable.

GDPR has given some good thought to automated decision making and has guidance that I think all companies should follow even if they don’t need to follow the GDPR regulations.

“We regularly check our systems for accuracy and bias and feed any changes back into the design process.

As a model of best practice...

We have signed up to [standard] a set of ethical principles to build trust with our customers. This is available on our website and on paper.” [1]

[1] https://ico.org.uk/for-organisations/guide-to-data-protectio...

Is it easier to submit extensions to the Microsoft store? Last time I looked it was very closed off to a selection of hand picked extensions. To be fair this was probably over a year ago.

Yeah. My guess is 3rd Party provider is AWS S3 and a DB backup was accessed.

Something like this https://github.com/die-net/http-tarpit

I have things like Postgres, Redis, Rabbitmq, etc running in docker on my local machine for development. I have a recommended configuration/install prebuilt and kept updated for me, and if I want to test my apps against a new release of redis for example (major or minor) it’s trivial to run parallel versions.

> Unless the cost equation changes, it is hard to get business users to change their priority

With GDPR getting teeth (see recent fines of BA and Marriott) for security breaches, I think this is the beginning of that cost equation changing.

But also bear in mind this is a company who have someone with the title Chief Information Security Officer. If alarm bells didn’t start ringing for that person when this vulnerability was reported, then they likely aren’t the right person for the job. Especially as Zoom have customers in the EU so that person is also likely their nominated Data Protection Officer and should therefore be well aware of the privacy requirements imposed by GDPR and the penalties for a privacy breach (which someone secretly recording webcam footage would surely qualify as).

As for local helper agents accessible from the internet, you only need to browse google project zero to see what a bad idea that is.

I have a feeling many enterprises are going to be rapidly expanding their security and privacy teams and paying top dollar.

Yeah, the uploading of copyright infringing content is one aspect, but I was also wondering about just uploading rubbish and somehow generating fake listens or tricking real users into listening to your track (game the ranking algorithms to get it into recommended playlists) to get royalties.

Something like the Amazon ebook scams:

https://www.zdnet.com/article/exclusive-inside-a-million-dol...

https://www.inc.com/minda-zetlin/amazon-book-stuffing-author...

I’m not familiar with the process, but could there also have been a fraud aspect (not copyright) to this that wasn’t worth the effort required to prevent? Upload “songs”, generate lots of listens, get paid.

As long as the ONLY processing of the data is for fraud detection/prevention, then GDPR specifically allows it as a “Legitimate Interest”

Recital 47: “The processing of personal data strictly necessary for the purposes of preventing fraud also constitutes a legitimate interest of the data controller concerned…”

Recital 71: “decision-making based on … profiling should be allowed where expressly authorised by … law … including for fraud or tax evasion monitoring and prevention purposes”

So there's a few things to unpack here.

> with their own malicious version, designed to inject adverts into users’ browsers

Your very first example wouldn't be prevented by these changes.

> 42% of malicious extensions use the Web Request API

So 58% don't event need the Web Request API to do something malicious. So these changes don't really improve safety at all.

> hacking the extensions, buying control of popular extensions

Both these scenarios need to be addressed at a different level. Things like enforcing 2-factor for high value extension authors (> 100K installs or something). Also remember Google operate a walled garden here. No extension can be published on the store without being vetted. They should be identifying high profile/value extensions and subjecting them to additional checks.

For me, and I'm sure many people, my biggest threat vector is ads. They threaten my security (malicious/malware laden ads), my privacy (tracking), and performance (slow, bloated ads). My ad blocker protects me every day from this threat vector. Google are now definitively weakening mine and a lot of other peoples protection in order to improve the security of the few. To me this does not seem like a reasonable compromise, especially when there are alternative ways to address their concerns.

And I'm sorry, but I really don't trust the motivations of a company that makes billions of dollars a year off online advertising, that has publicly stated that Ad Blocking is a threat to their business model, to then be making a change that just so happens to cripple Ad Blockers.

So lets take an alternative look at this. The justification is that this improves privacy, security and performance. For who? I use 2 extensions, an Ad Blocker (uBlock Origin) and Password Manager.

uBlock Origin has over 10M installs and the author has stated publicly that they cannot effectively do what they do if this change goes ahead. I can guarantee that uBlock Origin does more to protect my privacy, security and performance than this change. How many people have been affected by malicious extensions? I seriously doubt it's greater than 10M. So to improve the privacy, security and performance for a few, they are going to make it worse for the many.

Surely there are better solutions to tackle this problem? Maintain the API but add in additional checks/vetting for any extensions that use it.

Just blocking capabilities will be restricted to enterprise. From the manifest V3 design doc (https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3Nzz...)

“API Changes WebRequest: Restrict the blocking capabilities of the webRequest API.”

This seems like massive spin. Their primary argument doesn’t wash. As far as I understand it the web request API will still exist and still allow extension developers to view all request data. They just won’t be able to block the request and change it (I.e block content from loading)

Personal email accounts also tend to leak into having access to employer systems, especially in tech. For example a lot of people use their personal email for Github, so once an attacker has access to your personal email they can move laterally into your employers private code repositories.

BitGo should be treating this as a security incident and verifying the attacker didn’t also target them.

Agreed. But you can hack their replacement programs to extend the life of the newer (post 2015) models. There are a few battery replacement programs on MacBook Pro’s (e.g. https://www.apple.com/support/13inch-macbookpro-battery-repl...) and there is also a keyboard replacement program (https://www.apple.com/support/keyboard-service-program-for-m...). Replacing either practically gives you all new internals because of they way everything is soldered on. I just did that on my 2016 model and it should hopefully last me now a few more years.

In the EU this is a violation of GDPR if true.

That doesn’t help stop the attacks using breach lists that are even more prevalent.

You could start with email warnings of suspicious activity and fine tune the model parameters based on feedback from false positives. But generally a login from a device that has no previous cookie, from an ASN the account has never used before, especially if that ASN is a known data center, that then immediately attempts a destructive action, should be a pretty big warning flag.

While the fault lies with the users for not following security best practices, including enabling 2FA there are things gitlab/any site can do to help defend against these sorts of attacks. Some suggestions: Treat logins from datacenters as suspicious. (In this case the IP block identified belongs to World Hosting Farm Limited). Treat logins from a new/different ISP as suspicious. Limit access to the account and verify the login via email. It’s not foolproof but as part of a defense in depth strategy it can be quite effective.

In Europe at least it would probably be a violation of GDPR to not actually delete it on request of the user if it is considered personal data.

There is an argument that you should absolutely be optimising for day 1. One of your biggest advantages as a startup is agility. Until you've hit upon product/market fit, you want to choose tools that enable you to iterate fast.

Quite a few of the coffee shops I go to have started using these:

https://www.vegware.com/biodegradable-hot-cups/cat_4.html

The problem is that they require heat to activate the composting process, so need special bins that are sent to commercial composting centers, and there are none of those bins around, so they end up in regular garbage bins.

The most frequent use cases for us in order of use-fullness:

1. Spotify

2. TV control (with Harmony) - great for the kids so they don't break the remotes

3. Home monitoring when we are away (drop in on the echo spot).

But for me home security seems to be an unexplored opportunity for Amazon (and Google). Those microphones are very sensitive - and if paired with motion sense on other devices (a Nest or something) start to give you powerful intrusion detection tools and alerting. How hard would it be for them to recognise the sound of breaking glass or the presence of someone in the room at a time they shouldn't be there?

Obviously solving the pet issue is a challenge, but I think it's an interesting use case to explore.